Saloon Sdk Generator Laravel Package

Product Decisions This Supports

• Build vs. buy for the API client layer. saloon-sdk-generator turns a maintained OpenAPI spec into a typed Saloon-based PHP SDK. The decision it unlocks is "do we hand-write and hand-maintain HTTP clients, DTOs, and auth wiring per integration, or do we generate them from a spec we already own?" For teams with more than one or two third-party integrations, generation typically wins on maintenance cost alone.
• Security posture on third-party HTTP surface area. Saloon v4 is an explicitly security-driven release (CVE-2026-33942, CVE-2026-33182, CVE-2026-33183) with no functional API changes. v1.6.0 lets generated SDKs target ^3.0|^4.0, which means we can pull the patched Saloon into existing SDKs without a coordinated rewrite. This is a "can we remediate the CVE without a roadmap slot?" answer — and the answer is yes.
• Upgrade sequencing across consuming services. Because generated SDKs remain compatible with both v3 and v4, the Saloon major-version bump does not force a lockstep release across every service that consumes a generated SDK. Services can migrate on their own schedule; the generator is not the bottleneck.
• Multi-authenticator product surfaces. The fix to use defaultAuth() (instead of getAuthenticator()) in multi-authenticator connectors aligns generated behavior with Saloon's intended override pattern and with single-authenticator connectors. This matters for products where a single integration supports multiple credential types — per-tenant API keys vs. OAuth, or user-scoped vs. app-scoped tokens — where inconsistent auth resolution produces exactly the kind of intermittent, hard-to-reproduce bug that burns support time.
• Contract-first roadmap hygiene. Adopting the generator creates a forcing function: the OpenAPI spec has to be accurate and versioned, or the generated code is wrong. That is a process investment, but it's the same investment that makes SDK versioning, changelogs, and deprecation policy tractable.
• Regeneration as a routine, low-ceremony operation. A release like this one — dependency-range widening plus a targeted behavioral fix, no API surface change — is the ideal case for treating SDK regeneration as routine maintenance rather than a project.

When to Consider This Package

Adopt when most of the following hold:

• You have a PHP/Laravel codebase and consume one or more REST APIs described by an OpenAPI/Swagger spec you control or can trust.
• You are maintaining more than one integration, or one integration with enough endpoints that hand-written request classes and DTOs have become a maintenance tax.
• You want typed request/response objects and centralized auth, retry, and error handling rather than ad-hoc Guzzle calls scattered across the codebase.
• You are prepared to own the generated output — check it into the repo or a private package, review the diff on regeneration, and pin the generator version in CI.
• You need Saloon v4 for security remediation and want generated SDKs that don't block that upgrade.

Look elsewhere when:

• The consumer stack is not PHP, or is PHP but not Laravel — verify the Laravel plugin assumption before committing.
• The API is GraphQL, gRPC, or SOAP, or the spec is stale, partial, or hand-maintained and unreliable. Generation amplifies spec drift into compile-time-looking errors that are really contract errors.
• You need a runtime-dynamic client (endpoints or shapes discovered at runtime) rather than generated static classes.
• Your organization cannot pin or fork a globally installed Composer CLI tool — this installs via composer global require, which is a supply-chain and reproducibility consideration for locked-down build environments.
• The integration is a single, tiny, stable endpoint. Hand-writing a request class is cheaper than standing up a generation pipeline.

How to Pitch It (Stakeholders)

For executives: This is developer tooling, not a runtime dependency. It converts an OpenAPI spec into a maintained PHP SDK, which reduces the ongoing cost of every API integration we own and makes security patching of our HTTP layer a routine update instead of a project. The v1.6.0 release is a good example of the payoff: our HTTP client library (Saloon) shipped a security release addressing three CVEs, and this generator update lets our generated SDKs adopt the patched version without changing any code we've written. No functional API changes, no forced migration, no customer-visible behavior change.

For engineering: v1.6.0 widens the generated-SDK dependency constraint to ^3.0|^4.0 and upgrades the generator's own Saloon and Laravel-plugin dependencies to ^4.0. Saloon v4 is a security release only — generated SDKs behave identically on v3 and v4, so upgrading is a dependency-range change, not a code change. One item to verify before rolling out: multi-authenticator connectors now call defaultAuth() instead of getAuthenticator(). This is a correctness fix that brings them in line with single-authenticator connectors and Saloon's intended override pattern, but any connector with a custom authenticator override should be regenerated and smoke-tested — if a connector relied on the old resolution path, its auth behavior will change. Recommend pinning the generator version, regenerating into a branch, and diffing the output so the auth change is reviewed rather than absorbed silently.

Recommendation: Adopt v1.6.0. Low risk, clears a known CVE path, and the single behavioral change is scoped and reviewable.