Partner Laravel Package

Product Decisions This Supports

• Build vs. buy on integration plumbing. gando/partner is a Speakeasy-generated PHP client for a Partner API (OpenAPI 1.0.0). It answers the narrow question "do we hand-write HTTP/auth/pagination/serialization code for this partner, or consume a generated SDK?" — not the bigger question of whether the partnership itself is worth building against.
• Partner/reseller integration roadmap sequencing. A Composer-installable client is a prerequisite for any Laravel-side partner feature (onboarding, provisioning, referral or revenue-share flows). Its existence raises the confidence and lowers the estimate for those roadmap items, so it can justify pulling them forward.
• Vendor-SDK vs. self-generated-client strategy. Because this artifact is machine-generated from a versioned OpenAPI doc, the PM has a real alternative: generate our own client from the same spec and own the diff. That is a repeatable policy decision across every partner integration, not a one-off.
• Dependency and version-pinning policy. Shipping a 0.x package into production forces an explicit stance — pin exact versions, wrap behind an internal adapter interface, or vendor the code — which is a governance decision that outlives this package.
• Support and on-call scoping. Auto-generated clients shift failure modes to schema drift and silent regeneration rather than hand-written logic bugs. That changes who owns breakage (integration team vs. vendor) and how much monitoring the feature needs.

When to Consider This Package

Consider it when:

• The Partner API is genuinely on the roadmap within the next one to two quarters, and the spec (OpenAPI 1.0.0) is the source of truth you are already tracking for changes.
• You want the fastest credible path to a Laravel-side prototype — generated DTOs, typed requests, and auth handling beat hand-rolling HTTP calls for a spike or an internal tool.
• You are willing to treat it as a replaceable leaf dependency: consumed behind an internal interface or repository class, with the exact version pinned.
• Your team has no existing PHP/HTTP abstraction that already covers this partner, and no one has bandwidth to maintain a bespoke client.
• You can absorb regeneration churn — i.e. the integration is early, low-blast-radius, or gated behind a feature flag.

Look elsewhere when:

• You need production stability guarantees today. At 0.1.11 the package is pre-1.0; SemVer permits breaking changes in the minor position, and this release ships with no human-written changelog — only "Publishing Completed."
• Change review matters. The release note is a CLI transcript. There is no stated diff of endpoints, fields, or signatures. A PM cannot sign off on an upgrade they cannot read, and an engineer cannot triage a regression from it. If you need auditable change history (regulated, contractual, or high-traffic surfaces), prefer generating and diffing the client in-house from the pinned spec.
• The Partner API is incidental or read-only in a couple of calls — a thin hand-written client is less surface area than a generated SDK.
• You cannot accept vendor-controlled release cadence into your dependency graph.

How to Pitch It (Stakeholders)

For executives: This is a free, auto-generated client library for one of our partner APIs — a commodity wrapper, not a strategic asset. It shortens the "first working integration" phase from days to hours and lets us demo partner flows sooner. The trade-off is maturity: it is a pre-1.0 artifact regenerated by a tool, published without a readable changelog, so we should budget it as a prototype accelerator rather than a permanent foundation, and keep the underlying API spec — not the library — as the thing we contract against.

For engineering: Treat gando/partner as generated output, not source. Pin the exact version in composer.json, consume it behind an adapter we own, and add a contract test against the partner's OpenAPI 1.0.0 document so a regeneration that shifts a field or signature fails our build rather than production. Note that v0.1.11 carries no changelog beyond the Speakeasy CLI version and the fact of publication — assume the public surface is not guaranteed stable and verify the diff before any bump. If regeneration frequency or opacity becomes painful, the fallback is straightforward: run Speakeasy ourselves against the pinned spec and own the diff, which costs little and buys full change visibility.

Ask: approve a timeboxed spike against the partner API using this package, on the condition that the integration sits behind an internal interface and the version is pinned — so the decision to keep or replace the library stays cheap either way.