- How do I install sburina/laravel-whmcs-up in a Laravel application?
- Install it with Composer using composer require sburina/laravel-whmcs-up, then publish the package configuration file with the vendor:publish command. Add your WHMCS base URL, API identifier, API secret, and WHMCS_TIMEOUT value to your .env file so the client can authenticate against your billing instance. Because v2.0.0 targets PHP 8.2+ and Laravel 10+, confirm your host application meets those requirements before installing.
- Does this package still use WHMCS AutoAuth, or the newer SSO token approach?
- Version 2.0.0 replaces the old AutoAuth helpers (getAutoLoginUrl and redirectAutoLogin) with a CreateSsoToken-based flow. AutoAuth was removed in WHMCS 8.1, so any application still calling the old methods is talking to a decommissioned API surface. If your WHMCS is on 8.1 or newer, v2.0.0 is effectively the only supported path for single sign-on into the portal.
- Which Laravel and PHP versions does laravel-whmcs-up require?
- Version 2.0.0 requires PHP 8.2 or newer and Laravel 10 or newer, and Lumen support has been dropped because Lumen is end-of-life. The published compatibility table lists Laravel 10 through 13, but treat the Laravel 13 column as forward-looking rather than a tested guarantee and pin to the highest version you actually run in CI. If any service in your estate is still on Lumen or an older Laravel, that service needs its own upgrade path before it can adopt v2.
- Can I test WHMCS API calls with Http::fake() instead of mocking Guzzle?
- Yes. Version 2.0.0 is built on the Illuminate\Support\Facades\Http client, so outbound WHMCS requests go through Laravel's HTTP layer rather than raw Guzzle handlers. That means Http::fake() works for stubbing and asserting WHMCS API responses in your test suite, and the calls also inherit Laravel's HTTP middleware, retry hooks, and request events. This is a significant improvement over the v1 approach of mocking Guzzle handlers directly.
- Why did users get logged out of the WHMCS portal after upgrading to v2.0.0?
- The default session key changed from user to whmcs_user in v2.0.0, which is a silent behavioural change. Existing sessions still hold the old key, so users lose their WHMCS linkage and appear logged out of the portal with no error raised. Any downstream code that reads session('user') directly will also break without a stack trace, so plan an explicit transition rather than relying on the new default.
- How do I fix SSL certificate verification errors against a self-signed WHMCS instance?
- SSL verification is enabled by default in v2.0.0, which is correct for production but will immediately break non-production, on-premise, or internally signed WHMCS instances. The failures usually surface as what looks like broken SSO, when the real cause is certificate trust. Configure the appropriate verification option for those environments, or obtain a sanctioned opt-out with a clear owner and scope rather than disabling verification globally.
- Can this package be used as a Laravel user provider for WHMCS accounts?
- Yes. The package ships an authentication user provider for WHMCS, and v2.0.0 implements rehashPasswordIfRequired() on the UserProvider contract, which confirms it integrates at the auth-provider layer rather than being just an API wrapper. Because it sits directly in the login path, treat it as tier-1 infrastructure with proper monitoring and failure handling. Note that any WHMCS outage or timeout can block logins, so decide on a user-facing fallback behaviour up front.
- What should I set WHMCS_TIMEOUT to, and how do timeouts affect logins?
- WHMCS_TIMEOUT is a new environment variable in v2.0.0 that controls how long the HTTP client waits for a WHMCS API response. Because the user provider runs on the login path, a slow or unreachable WHMCS instance directly delays or blocks authentication, so set the value per environment and keep it tight in production. Also decide in advance what users should see when the WHMCS call times out during login, rather than letting a raw exception surface.
- Can I roll back to v1.x if the v2.0.0 upgrade causes problems?
- Realistically, no, at least not on the WHMCS axis. Once your WHMCS instance is on 8.1 or newer, AutoAuth is gone upstream, so v1.x cannot function as a fallback. That makes the WHMCS upgrade a one-way door, and the package swap should be planned together with the coordinated PHP, Laravel, and WHMCS upgrades rather than as an isolated change.
- Does the package support ordering or filtering clients through sbGetClients()?
- Yes, sbGetClients() supports ordering and filtering via parameters such as orderby and status, but those parameters depend on WHMCS 8.2 or newer. If you need that behaviour, your minimum supported WHMCS version rises from 8.1 to 8.2, which affects your upgrade ownership and test matrix. Verify the target version in every environment before depending on the filtered call.