Core Laravel Package

Product Decisions This Supports

• Build vs. buy for client SDKs. This package is the runtime half of APIMatic's codegen offering: generated PHP SDKs call into it for request building, parameter handling, response deserialization, error mapping, and auth. Adopting it is really a decision about whether to buy SDK generation rather than hand-write clients — the decision point is the generator, not this library.
• Whether to ship an official PHP SDK at all. If your API program has (or wants) a "first-party SDK" checkbox on the roadmap, this is the cheapest credible path: you keep an OpenAPI spec, generate, and publish. If PHP is a minority language for your customers, defer.
• Multi-language SDK parity. Choosing a generator with a shared runtime model across languages (this is the PHP counterpart to APIMatic's other core libs) supports a strategic decision to offer consistent SDK behavior — same auth model, same error surfacing, same logging — across languages rather than per-language bespoke clients.
• Support and debuggability commitments. The logger module (LoggingConfiguration, RequestConfiguration, ResponseConfiguration, NON_SENSITIVE_HEADERS) lets you decide that SDKs ship with opt-in request/response logging and header redaction. That is a support-cost decision: it determines whether your team can diagnose customer integration issues from a log dump.
• Contract testing as a release gate. CoreTestCase plus body/header/status matchers enable generated acceptance tests that assert against recorded API responses. This supports a decision to gate API changes on SDK contract tests before publishing.
• API design fidelity. Support for oneof/anyOf discriminators, multiple auth schemes, and RFC3339/simple-date handling means your roadmap can include richer OpenAPI constructs (polymorphic payloads, multi-scheme auth) without the PHP SDK silently degrading them.
• PHP version support matrix. Support for PHP 7.2 through 8.4 supports a decision to serve long-tail enterprise customers on legacy runtimes, not just modern PHP.
• Not a decision this supports: adopting it as a general-purpose HTTP client in your own application code. It is an implementation detail of generated SDKs, not a library you'd composer require to make API calls by hand.

When to Consider This Package

Consider it (indirectly, via APIMatic-generated SDKs) when:

• You maintain a public or partner-facing REST API with an OpenAPI/Swagger spec and want to publish a PHP SDK without dedicating engineers to hand-maintaining it.
• You need SDKs in several languages and value a consistent runtime model across them more than per-language idiomatic purity.
• Your API surface uses constructs that naive generators mishandle — discriminated unions, multiple simultaneous auth schemes, form/multipart bodies, template path params — and you need a runtime that already has abstractions for them (AdditionalFormParams, AdditionalHeaderParams, TemplateParam, ResponseMultiType).
• You need built-in request/response logging with sensitive-header filtering for customer support.
• You want generated acceptance tests with matchers as part of the delivery pipeline.
• You are buying APIMatic anyway; the runtime comes along at no additional integration cost.

Look elsewhere when:

• You only need one PHP client and it is internal. Hand-write against Guzzle, Symfony HttpClient, or Saloon. You get PSR-18/PSR-7 interoperability, middleware, retries, and a hiring pool familiar with the ecosystem; this library is not PSR-based and its request/response types are its own.
• You require open, vendor-neutral tooling. This is a single-vendor runtime with no independent community — 7 stars and no publicly listed dependents. Debugging generated code means reasoning about APIMatic's abstractions, and support leverage sits with the vendor. Prefer OpenAPI Generator or hand-rolled clients if procurement or longevity review is strict.
• You need ecosystem middleware (circuit breakers, caching, retry policies, tracing via PSR-18 plugins). Nothing here composes with those.
• You cannot tolerate pre-1.0 semantics. Releases sit in 0.3.x with feature and fix churn, including behavior changes like exception wrapping and auth validation. If you need a stable, semver-guaranteed API surface for internal code, treat the generated SDK as the contract floor and pin aggressively.
• You want the runtime to be independently upgradeable. You usually don't control it directly — the generated SDK's composer.json pins a core version range, so security patches land on the generator's cadence, not yours. Verify the range before committing to a support SLA.
• You need retries, rate-limit handling, or resilience built in. Not evidenced in this package's surface; plan to implement at the application layer.

How to Pitch It (Stakeholders)

For executives. Our API's adoption depends on how fast a customer can make a first successful call. Every bespoke PHP client we write is maintenance we carry forever across PHP 7.2 to 8.4, and every breaking API change becomes a manual client migration. Generating SDKs from our OpenAPI spec moves that cost from headcount to a vendor line item, keeps shipped clients consistent across languages, and gives us a repeatable release artifact. The runtime is MIT-licensed, actively released, and handles the unglamorous parts — serialization, error mapping, auth, logging with secrets redacted — so our generated code stays thin. The strategic trade-off to accept is vendor dependency and a small community footprint; the mitigation is that generated clients are reproducible artifacts, not hand-crafted assets, so we can regenerate or exit if needed.

For engineering. This is the runtime dependency your generated SDK will call, not something you integrate by hand. It gives you: a request builder with typed parameter classes and template/auth handling; response handling with typed deserializers, multi-type responses, discriminator support, and exception mapping (it throws real exceptions, not wrappers); a configurable logger with sensitive-header filtering; and a CoreTestCase with body/header/status matchers for acceptance tests. Everything is PHP 7.2–8.4 compatible and MIT. What it does not give you: PSR-18/PSR-7 interop, Guzzle middleware, retries, or backoff. Budget for those at the application layer and pin the core version the generator emits. Treat the library as an opaque, vendored dependency — do not subclass or couple business logic to its internals, because it is pre-1.0 and its surface still moves.