- How do I install darthsoup/laravel-whmcs in a Laravel application?
- Install it with Composer using composer require darthsoup/laravel-whmcs, then publish the config file with php artisan vendor:publish. The service provider is auto-discovered, so no manual registration is required on supported Laravel versions. After publishing, add your WHMCS URL and API credentials, and you can start calling the API through the facade. Setup is typically a matter of hours, not days, for a developer familiar with Laravel package conventions.
- Which Laravel and PHP versions does darthsoup/laravel-whmcs support?
- Support is defined entirely by the illuminate and php constraints in the package's composer.json, so check the manifest at the exact tag you plan to use rather than trusting the changelog title. Release 1.4.0 added Laravel 13 compatibility, but you need to verify whether the constraint was widened additively or replaced, because a replaced constraint would silently drop Laravel 11 and 12 support. If your app is on Laravel 11 or 12 and support was dropped, pin 1.3.0 deliberately and record the reason. There is no documented backward-compatibility or support-matrix policy for this pre-2.0 package.
- How do I configure the WHMCS API URL and credentials in Laravel?
- Credentials live in the publishable config file, which you should populate from environment variables rather than committing secrets. On the WHMCS side you must enable API access, create an API role with the permissions your calls need, and add your server IP to the allowlist. Be aware that WHMCS error responses can echo request parameters, so review where exceptions and logs are written to avoid leaking credentials or customer data. Diff the config file after any upgrade, since vendor:publish will not overwrite an existing one.
- What WHMCS operations can I perform with darthsoup/laravel-whmcs?
- The package is a thin transport wrapper that sends form-encoded POST requests to WHMCS's includes/api.php endpoint, covering the standard API actions for clients, orders, invoices, products, and services. It does not model WHMCS entities, abstract them into a domain layer, or sync data automatically. Billing and provisioning logic stays in your application, and WHMCS remains the source of truth for customers, invoices, and subscriptions. Treat it as a third-party HTTP client rather than a subsystem to build on.
- Why does my WHMCS API call return an error inside a normal HTTP 200 response?
- That is expected WHMCS behaviour: the API returns HTTP 200 even when the operation failed, and the failure is signalled inside the body by a result field set to error with a message. Your code must inspect the result field rather than relying on the HTTP status. The package's WHMCS response parsing is the area most exposed to WHMCS payload changes, so exercise every action you call. Confirm that error handling and result=error paths are covered in your own tests, since the package's CI tells you little about API-level fidelity.
- Can darthsoup/laravel-whmcs replace WHMCS or Laravel Cashier for billing?
- No. The package is only a client for the WHMCS API, so WHMCS continues to own customers, invoices, orders, and service provisioning. It does not replicate billing logic and will not substitute for Cashier or a bespoke billing implementation. It slots in alongside your existing billing code without conflict because it makes no assumptions about your billing model. Use it to push and pull data from WHMCS, not to replace it.
- Is darthsoup/laravel-whmcs actively maintained and safe for production?
- It is a single-maintainer project with a bus factor of one, and it sits below version 2.0 with no stated backward-compatibility policy, so treat upgrades as deliberate decisions. The 1.4.0 release itself looks low risk because its diff is limited to a Laravel 13 compatibility change and a CI workflow fix. The real risks are inherent to the package: HTTP client behaviour, WHMCS API semantics, and uncertain test coverage against a live instance. Pin versions, wrap the client behind a small interface of your own, and have a fork contingency in mind.
- How do I upgrade darthsoup/laravel-whmcs from 1.3.0 to 1.4.0 safely?
- Read the composer.json diff at tag 1.4.0 before changing anything, because that is where Laravel version support is actually defined. Then update the constraint or run composer update darthsoup/laravel-whmcs in a branch, diff your published config, and confirm the facade alias still resolves. Run your own test suite plus integration tests against a WHMCS sandbox rather than relying on the package's CI alone. If the new constraint replaced rather than widened support for your Laravel version, stay on 1.3.0 intentionally.
- How should I test darthsoup/laravel-whmcs, and do I need a WHMCS sandbox?
- Yes, a sandbox or staging WHMCS instance is strongly recommended, because mocked responses will not reveal changes in WHMCS payload shape or permission errors from your API role. The package's own CI fix shows tests run, but it says nothing about how faithfully the tests reproduce the real API. Exercise every action you actually call, including failure cases that come back as result=error with HTTP 200. Keep those integration tests in your application so they catch breakage on both package and WHMCS upgrades.
- What are the alternatives to darthsoup/laravel-whmcs?
- Alternatives are other WHMCS API wrappers for Laravel, or simply calling the WHMCS API yourself with Laravel's HTTP client, which is viable because this package is only a thin, form-encoded POST wrapper with a facade. Writing your own gives you full control over error handling, credential redaction, and response typing at the cost of a little boilerplate. Choosing the package gets you a service provider, publishable config, and facade convenience out of the box. Either way, WHMCS API version compatibility and maintenance ownership are the factors worth weighing most.