Laravel Fortnox Laravel Package

Technical Evaluation

Architecture fit: The package remains a narrow Laravel Socialite driver for Fortnox OAuth. It sits in the authentication/integration layer and is on the critical path for token refresh and Fortnox API calls. The 0.2.0 fix aligns driver registration with Laravel 13’s manager rebinding behavior, which is an important architectural correctness fix for apps using the Socialite manager lifecycle.

Integration feasibility: Feasible for applications already on Laravel 12 or 13. The new FortnoxSocialiteProvider::resolve() accessor provides a typed way to obtain the registered driver and reduces reliance on Socialite-manager internals. Applications still on Laravel 11 cannot adopt 0.2.0 without a framework upgrade, so feasibility depends on the fleet’s Laravel baseline.

Technical risk: The highest-risk change is the intentional drop of Laravel 11 support. This is a breaking compatibility change for any Laravel 11 service, even though it is a minor release in a pre-1.0 package. The prior Laravel 13 driver-resolution failure was high severity because it broke token refresh and every subsequent API call; 0.2.0 addresses that failure mode. Residual risk includes upstream Socialite/Laravel changes affecting driver registration, token refresh behavior, and dependency constraints.

Key questions:

• Which applications or services currently depend on this package, and what Laravel versions are they on?
• Do any Laravel 11 services require the Laravel 13 driver fix, forcing a framework upgrade rather than a package-only upgrade?
• Is resolve() expected to become the supported access pattern, or is it additive convenience?
• What Socialite and PHP versions are supported by 0.2.0, and are those documented?
• Are there automated tests covering Laravel 12 and 13 driver resolution, token refresh, and Fortnox API calls?
• What is the package’s support policy for pre-1.0 breaking changes?

Integration Approach

Stack fit: Best fit is a Laravel 12/13 application using Laravel Socialite for Fortnox authentication and token refresh. The package is not a standalone OAuth implementation; it depends on the host application’s Laravel/Socialite stack and Fortnox configuration.

Migration path: For Laravel 12/13 applications, upgrade from 0.1.x to 0.2.0 and validate driver resolution, token refresh, and Fortnox API calls. For Laravel 11 applications, either remain pinned to the prior package line with an explicit risk acceptance or schedule the Laravel 12/13 framework upgrade before adopting 0.2.0. Avoid mixing package upgrades across services without confirming each service’s framework baseline.

Compatibility: 0.2.0 requires Laravel 12 or 13. Laravel 11 is no longer supported. Confirm the host application’s Socialite version, PHP version, and dependency constraints before rollout. The new resolve() accessor should be adopted where code currently reaches into Socialite internals or relies on untyped driver retrieval.

Sequencing:

1. Inventory services using the package and classify by Laravel version.
2. Upgrade Laravel 11 services to Laravel 12/13 if they need 0.2.0; otherwise pin and document the exception.
3. Upgrade the package in a canary Laravel 12/13 service.
4. Smoke-test Fortnox OAuth callback, driver resolution, token refresh, and a representative API call.
5. Update CI matrices to include Laravel 12 and 13.
6. Roll out to remaining compatible services with rollback pins available.

Operational Impact

Maintenance: Maintenance burden should decrease for Laravel 12/13 fleets because the package now handles Laravel 13’s manager rebinding correctly. However, dropping Laravel 11 creates short-term coordination work. The pre-1.0 versioning means minor releases may still carry breaking changes, so dependency updates should be reviewed rather than auto-merged.

Support: Support teams should expect questions around Laravel 11 incompatibility and the “No Socialite driver was specified” error on older package versions under Laravel 13. Document the minimum supported Laravel version and the recommended resolve() usage pattern. Keep a known-good pinned version for any service that cannot yet meet the framework requirement.

Scaling: The package itself is unlikely to be a scaling bottleneck; Fortnox token refresh and API rate limits are the practical constraints. Ensure token caching and refresh handling are centralized so a driver-resolution failure does not cascade across workers or queued jobs.

Failure modes:

• Installing 0.2.0 on Laravel 11 causes dependency/compatibility failure.
• Running older package versions on Laravel 13 can produce “No Socialite driver was specified,” breaking token refresh and downstream Fortnox API calls.
• Incorrect driver registration or configuration can fail OAuth callbacks.
• Token refresh failures can surface as broad API failures unless alerts distinguish auth-layer failures from business API failures.
• Direct reliance on Socialite manager internals may break if upstream behavior changes again.

Ramp-up: Low for Laravel developers familiar with Socialite. New integrators need Fortnox OAuth credentials, callback configuration, and an understanding of token refresh. TPM should require a short integration runbook covering Laravel version constraints, driver resolution, token refresh verification, and rollback pinning.