SDK generation

Generate a PHP SDK from OpenAPI: end-to-end in 2026

Two tools generate a working PHP SDK from an OpenAPI spec in 2026: OpenAPI Generator's php or php-nextgen templates, and Jane, a PHP-native generator built for the Symfony ecosystem. Jane produces more idiomatic PHP if you're already on Symfony; OpenAPI Generator is the safer default if you're not, or if you're generating SDKs for five languages from one pipeline and want one tool. Sourced's hosted pipeline doesn't generate a PHP SDK — for PHP, use Jane or OpenAPI Generator, covered below; see "Where Sourced fits" further down for what it does cover.

PHP SDK generators compared

Tool Maintained (Sept 2026) Output style Best for
OpenAPI Generator (php) Yes — v7.25.0, released Aug 24 2026 Guzzle-based client, mature templates Teams already using OpenAPI Generator for other languages
OpenAPI Generator (php-nextgen) Yes, same release — marked beta by its own docs PSR-18 / modern PHP client Teams that want PSR-18 output and can tolerate beta status
Jane Yes — v7.14.3, released Sept 8 2026 Symfony HttpClient, typed models + normalizers Symfony shops, teams wanting idiomatic PHP

Option 1: OpenAPI Generator

OpenAPI Generator is the multi-language codegen project used across dozens of target languages. Its PHP output comes in two generator names: php (the original, Guzzle-based, HTTP library defaults to guzzle with a beta psr-18 option) and php-nextgen (a newer client generator that OpenAPI Generator's own docs label generator stability: BETA as of this writing).

# Original php generator (Guzzle-based, stable)
npx @openapitools/openapi-generator-cli generate \
  -i ./openapi.yaml \
  -g php \
  -o ./generated

# php-nextgen (PSR-18-oriented, beta)
npx @openapitools/openapi-generator-cli generate \
  -i ./openapi.yaml \
  -g php-nextgen \
  -o ./generated

Pick php if you want the stable, longer-track-record path. Pick php-nextgen only if you specifically need PSR-18 output and can absorb beta-quality rough edges — check the generator's own metadata before committing a production pipeline to it.

Option 2: Jane

Jane is purpose-built for PHP: it reads an OpenAPI 2.0, 3.0.x, or 3.1.x spec and generates a client built on Symfony's HttpClient, plus typed models and normalizers, wired for Symfony's Serializer component. It's actively maintained — the janephp/janephp repo shipped v7.14.3 on September 8, 2026, and has commits within the last day as of this writing.

Install the runtime and the generator for your spec's OpenAPI version (Jane detects which one you're using):

composer require --dev jane-php/open-api-3
composer require jane-php/open-api-runtime

Write a .jane-openapi config file (a PHP script returning an array):

<?php
return [
  'openapi-file' => __DIR__ . '/openapi.yaml',
  'namespace' => 'Vendor\Library\Generated',
  'directory' => __DIR__ . '/generated',
];

Then generate:

php vendor/bin/jane-openapi generate

That produces a Client class with a static create() factory, one endpoint class per operation, typed models, and normalizers — everything wired through Symfony's Serializer if you're using the Symfony recipe. Method names come from operationId; a missing operationId gets one derived from the path, which is worth avoiding by fixing your spec instead (see OpenAPI best practices for SDK-friendly specs).

Which one should you use

If your team is on Symfony, or wants PHP that reads like it was hand-written by a PHP developer, use Jane — it's the more actively maintained, PHP-idiomatic option as of September 2026. If you're generating SDKs across several languages already with OpenAPI Generator and want one config format and one CI step, use OpenAPI Generator's php (not php-nextgen, until it graduates out of beta).

Either way, run the same spec hygiene checklist first: every operation needs an operationId, schemas belong in components/schemas (not inlined), and security schemes need to be defined. A generator can't fix a bad spec — see the full list in OpenAPI best practices for SDK-friendly specs, or catch the issues automatically with Sourced's OpenAPI validator before you run codegen.

Where Sourced fits (and doesn't)

Plainly: Sourced's generated SDKs focus on TypeScript and Python today — the two ecosystems where teams publish first — see how that works for TypeScript and Python. If PHP is your target, generate it with Jane or OpenAPI Generator above, and bring Sourced in for the part of the workflow it does own: docs, llms.txt, and validation on the same spec.

What Sourced does add on top of any language, PHP included, from the same OpenAPI spec you're already feeding to Jane or OpenAPI Generator:

  • Hosted docs generated from the spec, with a private preview URL, free to try — no separate docs toolchain to run alongside your PHP codegen.
  • llms.txt generation so your API is readable by LLM agents, with no extra config. Try the llms.txt generator.
  • OpenAPI validation that catches the spec issues that produce bad PHP output before you run any generator — openapi-validator.
  • Spec diffing between versions, so you know what changed before your PHP client (or any client) breaks — openapi-diff.

The practical move: generate your PHP SDK with Jane or OpenAPI Generator, and give the same OpenAPI spec to Sourced for free hosted docs, llms.txt, and validation in one pass. Create hosted docs from your repo or start free — unlimited previews, up to 2 hosted noindex docs review sites and one hosted MCP server, no credit card.

Generating SDKs in other languages

Same spec, different target language — see TypeScript, Python, Rust, Kotlin, Swift, Go, Java, C#, and Ruby.

FAQ

Does Sourced generate PHP SDKs?

No — see "Where Sourced fits" above for what Sourced covers instead. For PHP, use Jane (Symfony-native) or OpenAPI Generator's php generator, covered above.

Is php-nextgen in OpenAPI Generator ready for production?

As of September 2026, OpenAPI Generator's own documentation marks php-nextgen's generator stability as BETA. The original php generator (Guzzle-based) has a longer track record and is the safer default for production pipelines.

Is Jane only for Symfony projects?

Jane's generated client is built on Symfony's HttpClient and, if you use the Symfony recipe, wires into Symfony's Serializer automatically. You can use Jane outside a full Symfony app — the generated client and runtime package (jane-php/open-api-runtime) work standalone — but the deepest integration (autowiring, the bundled config) assumes Symfony.

What PHP version does the generated code target?

This depends on the generator version and template you pick, not the OpenAPI spec. Check the specific generator's current requirements before generating — both OpenAPI Generator and Jane update PHP version support with new releases.

How do I stop my PHP SDK from drifting from the API?

Regenerate on every spec change and diff the public surface (method names, parameter shapes) between versions. Sourced's spec-diff tool does this against your OpenAPI spec directly, independent of which language generator you use.

Can I generate a PHP SDK and still use Sourced for docs?

Yes — that's the intended split. Run Jane or OpenAPI Generator locally for the PHP SDK, and point Sourced at the same spec for hosted docs, llms.txt, and validation. Nothing about Sourced's docs pipeline requires using Sourced's SDK generator.