Product Decisions This Supports
- Xero integration scoping and sequencing. The SDK is the official, OpenAPI-generated PHP client for Xero's Accounting, Payroll, Projects, Assets and related APIs. If Xero connectivity is on the roadmap, this package defines how much of that surface (invoices, contacts, bank transactions, manual journals, payroll) is reachable without bespoke HTTP work — useful for sizing epics and deciding which Xero domains to ship first.
- Build vs. buy for the integration layer. Choosing this package means buying the wire-format and model layer (OAuth2 flows, token refresh, typed request/response models, pagination, rate-limit handling conventions) and only building the parts that are genuinely product-specific: sync strategy, mapping to internal domain objects, reconciliation rules, and webhook handling.
- Upgrade and dependency-risk planning. The 16.2.0 release (OAS: 19.0.0) is a spec-regeneration release: the bundled OpenAPI definition moved to 19.0.0 and the generated client models/endpoints were rebuilt accordingly. Because it is a minor bump from 16.1.0, semver implies no intended breaking changes for consumers, but regenerated models can still shift in practice — newly added fields, changed nullability, new enum values, or new optional query parameters. Treat this as a low-risk maintenance release that should still be validated against our integration tests before promotion, and pin the version in
composer.json rather than floating.
- Maintenance-health signal for the vendor dependency. The release is produced by Xero's own automation (
@xero-public-bot) from their published OAS. That confirms the SDK tracks Xero's contract on a regular cadence, which lowers the risk of adopting it as a long-lived dependency and reduces the need to maintain a hand-rolled client.
- API-version negotiation. Keeping the SDK reasonably current is how we stay aligned with Xero's supported API surface; falling several OAS versions behind is a roadmap risk for any Xero-facing feature.
When to Consider This Package
Adopt when:
- The product is PHP/Laravel and needs server-side, multi-tenant Xero connectivity (connect a customer's Xero org, store and refresh OAuth2 tokens, call Accounting/Payroll endpoints).
- Breadth matters: you expect to touch multiple Xero API domains over time and do not want to hand-maintain request/response models for each.
- Your team values vendor-owned, spec-generated clients over community wrappers, and can absorb a dependency whose major versions occasionally regenerate large swaths of models.
- You need OAuth2 authorization-code flow and token refresh handled for you, since that is the SDK's core value beyond raw HTTP.
Look elsewhere or build thin when:
- You need only one or two read-only endpoints — a small Guzzle client may be less upgrade surface than a full generated SDK.
- You are not on PHP, or you need the integration isolated in a separate service (in which case a different language SDK or direct REST calls may fit better).
- You need first-class webhook ingestion, queuing, retry/backoff orchestration, or sync-state management — the SDK is a client library, not an integration framework; those remain our build responsibility.
- You require hard guarantees against model churn: generated clients can change shape on minor releases, so if your release process cannot tolerate that, budget for an adapter/anti-corruption layer around the SDK.
For this release specifically: no breaking changes are signalled (16.1.0 → 16.2.0). Schedule it as routine dependency maintenance, review the generated-model diff for new/changed fields and enums, and confirm our mapping layer handles any added nullable properties before rolling out.
How to Pitch It (Stakeholders)
For executives: Xero is a mainstream accounting platform for our target customers, and this is Xero's own official PHP SDK, actively maintained and regenerated directly from Xero's published API specification. Adopting it converts "build and maintain a Xero API client" into "build the product logic on top of a vendor-supported client," cutting integration effort and ongoing maintenance risk. The latest release (16.2.0) is a routine spec update with no signalled breaking changes — evidence the dependency is well-tended rather than a one-off library we would inherit.
For engineering: This is the official xero-php-oauth2 client, generated from Xero's OpenAPI spec, covering OAuth2 token lifecycle plus typed models for the Accounting/Payroll/Projects/Assets APIs. It solves transport, auth refresh, serialization and pagination; it deliberately does not solve webhooks, sync orchestration, idempotency or our domain mapping — plan for an adapter layer so SDK model changes stay contained. Version 16.2.0 bumps the embedded OAS to 19.0.0 and regenerates models under a minor version, so no breaking changes are intended: pin the version, run the contract/integration suite against a Xero sandbox, and watch the generated diff for nullability and enum additions.
Ask: approve adopting the package as our Xero client of record, with a pinned version and a standing maintenance ticket for SDK/OAS upgrades, and scope the adapter layer plus sync logic as our own workstream.