OpenAPI and Automatic Code Generation: Define Once, Generate Everywhere

A Brief History: From Swagger to OpenAPI

The story starts in 2009 when Tony Tam, CTO of the online dictionary service Wordnik, needed a way to document and manage their growing JSON API. The internal tool he built became Swagger — a name suggested by colleague Zeke Sikelianos as a playful jab at WADL (Web Application Description Language), the XML-heavy alternative that nobody enjoyed using.

The Swagger Years

Swagger 1.0 arrived in August 2011. It introduced a JSON-based format for describing RESTful APIs and shipped alongside tooling for interactive documentation and code generation. It was simple, practical, and solved a real problem that existing standards like WADL made painful.

Swagger 1.1 (August 2012) was a minor refinement. Swagger 1.2 (March 2014) was the first version written as a formal specification document, separating the spec from the implementation and improving the type system to align with JSON Schema Draft 4.

Swagger 2.0 (2014) was the inflection point. It simplified the specification structure, gained massive adoption, and triggered an explosion of third-party tooling. This was the version that made API-first design practical for most teams.

The OpenAPI Era

In March 2015, SmartBear Software acquired the Swagger specification. Later that year, SmartBear donated it to the newly formed OpenAPI Initiative under the Linux Foundation, with founding members including Google, IBM, Microsoft, and PayPal. On 1 January 2016, the specification was officially renamed to the OpenAPI Specification (OAS). The Swagger brand lived on as SmartBear's commercial tooling — the Editor, the UI, and Codegen — but the specification itself was now community-governed.

OpenAPI 3.0 (July 2017) was a major restructuring. It introduced the components object to consolidate reusable definitions, replaced the flat host/basePath/schemes fields with a flexible servers array supporting multiple environments, added callbacks for describing webhooks, introduced links for expressing relationships between operations, and overhauled request body handling with proper content negotiation via media types.

OpenAPI 3.1 (February 2021) achieved full compatibility with JSON Schema Draft 2020-12 — the single most requested change. The OpenAPI-specific nullable keyword was replaced by JSON Schema's native type arrays (type: [string, null]), $ref could finally coexist with sibling keywords like description, and a new top-level webhooks field provided first-class support for event-driven APIs. The paths field became optional, allowing specifications that described only webhooks or shared components.

OpenAPI 3.2 (September 2025) added hierarchical tags for better API organisation, support for the QUERY HTTP method, streaming support for Server-Sent Events and JSON Lines, OAuth 2.0 Device Authorisation Flow, and the additionalOperations keyword for non-standard HTTP verbs.

What Is an OpenAPI Specification?

An OpenAPI specification is a YAML or JSON document that describes everything about your HTTP API in a structured, language-agnostic format. It covers:

• Endpoints and operations — every URL path, HTTP method, and what each operation does
• Request and response schemas — the shape of every payload, with data types, validation rules, and examples
• Authentication — API keys, OAuth 2.0 flows, bearer tokens, mutual TLS
• Parameters — query strings, path variables, headers, and cookies
• Error responses — structured error formats for each status code
• Reusable components — shared schemas, parameters, responses, and examples

Here is a minimal but complete example:

openapi: 3.1.0
info:
  title: Product Catalogue API
  version: 1.0.0
  description: Manages products in the catalogue

servers:
  - url: https://api.example.com/v1
    description: Production
  - url: https://staging-api.example.com/v1
    description: Staging

paths:
  /products:
    get:
      operationId: listProducts
      summary: List all products
      parameters:
        - name: category
          in: query
          schema:
            type: string
        - name: limit
          in: query
          schema:
            type: integer
            default: 20
            maximum: 100
      responses:
        '200':
          description: A list of products
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Product'
    post:
      operationId: createProduct
      summary: Create a new product
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateProductRequest'
      responses:
        '201':
          description: Product created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
        '422':
          description: Validation error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'

  /products/{productId}:
    get:
      operationId: getProduct
      summary: Get a single product
      parameters:
        - name: productId
          in: path
          required: true
          schema:
            type: string
            format: uuid
      responses:
        '200':
          description: The product
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
        '404':
          description: Product not found

components:
  schemas:
    Product:
      type: object
      required: [id, name, price]
      properties:
        id:
          type: string
          format: uuid
        name:
          type: string
          examples: ['Wireless Keyboard']
        price:
          type: number
          format: float
          minimum: 0
        category:
          type: string
        createdAt:
          type: string
          format: date-time

    CreateProductRequest:
      type: object
      required: [name, price]
      properties:
        name:
          type: string
          minLength: 1
          maxLength: 255
        price:
          type: number
          format: float
          minimum: 0
        category:
          type: string

    ErrorResponse:
      type: object
      properties:
        message:
          type: string
        errors:
          type: object
          additionalProperties:
            type: array
            items:
              type: string

  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

security:
  - bearerAuth: []

That single document is both human-readable documentation and a machine-readable contract. It tells you what every endpoint expects, what it returns, how authentication works, and what the data looks like. More importantly, it tells tools all of that too — which is where code generation comes in.

Automatic Code Generation: The Big Win

The real power of OpenAPI is not documentation. It is the ability to feed that specification into a code generator and produce working, type-safe client libraries, server stubs, and data models in any supported language. You define the API once, and the tooling generates the tedious parts.

OpenAPI Generator is the primary open-source tool for this. It is a community-driven fork of Swagger Codegen with broader language support, more active maintenance, and an Apache 2.0 licence. As of 2026, it supports over 50 target languages and frameworks.

What Gets Generated

For a client SDK, OpenAPI Generator typically produces:

• Model classes / DTOs — typed objects matching every schema in your specification, with proper validation and serialisation
• API client classes — one class per tag or resource group, with a method for each operation
• Request and response handling — HTTP transport, content-type negotiation, error mapping
• Authentication — configured from the security schemes in your spec
• Configuration — base URL, timeouts, custom headers

For a server stub, it generates the routing, controller interfaces, request validation, and model classes — you fill in the business logic.

Supported Languages and Frameworks

The breadth of support is genuinely impressive. On the client side: PHP, TypeScript (with Axios, Fetch, or Angular variants), Python, Go, Java, Kotlin, C#, Ruby, Rust, Swift, Dart, and many more. On the server side: PHP (Laravel, Symfony, Slim, Mezzio), Java (Spring, JAX-RS), Python (Flask, FastAPI), Go, Node.js (Express, NestJS), and others.

There are also generators for documentation (HTML, Asciidoc), configuration (Apache, Nginx), database schemas (MySQL), and even GraphQL schema definitions.

The Workflow in Practice

Here is how a typical code generation workflow looks:

# Install OpenAPI Generator via npm (cross-platform wrapper)
npm install @openapitools/openapi-generator-cli -g

# Generate a PHP client from your spec
openapi-generator-cli generate \
  -i api-spec.yaml \
  -g php \
  -o ./generated/php-client \
  --additional-properties=invokerPackage=App\\ApiClient,composerPackageName=mycompany/api-client

# Generate a TypeScript Axios client
openapi-generator-cli generate \
  -i api-spec.yaml \
  -g typescript-axios \
  -o ./generated/ts-client

# Generate Laravel server stubs
openapi-generator-cli generate \
  -i api-spec.yaml \
  -g php-laravel \
  -o ./generated/laravel-server

You can also use Docker, which avoids the Java dependency entirely:

docker run --rm \
  -v "$(pwd):/local" \
  openapitools/openapi-generator-cli generate \
  -i /local/api-spec.yaml \
  -g php \
  -o /local/generated/php-client

The generated code is immediately usable. Install dependencies, configure the base URL and authentication, and you have a working client:

<?php

declare(strict_types=1);

use App\ApiClient\Configuration;
use App\ApiClient\Api\ProductsApi;
use App\ApiClient\Model\CreateProductRequest;

require_once __DIR__ . '/vendor/autoload.php';

$config = Configuration::getDefaultConfiguration()
    ->setHost('https://api.example.com/v1')
    ->setAccessToken('your-jwt-token-here');

$api = new ProductsApi(config: $config);

// List products - fully typed, auto-completed in your IDE
$products = $api->listProducts(category: 'electronics', limit: 50);

foreach ($products as $product) {
    // $product is a typed Product object, not a raw array
    echo $product->getName() . ': ' . $product->getPrice() . PHP_EOL;
}

// Create a product - the request object enforces the schema
$request = new CreateProductRequest([
    'name' => 'Wireless Mouse',
    'price' => 29.99,
    'category' => 'peripherals',
]);

$created = $api->createProduct($request);
echo 'Created: ' . $created->getId() . PHP_EOL;

Compare that to the alternative: manually writing HTTP calls with Guzzle or cURL, hand-mapping JSON arrays to objects, remembering which endpoints need which headers, and hoping the documentation is up to date. The generated client eliminates all of that.

What the Generated Code Looks Like

To make this concrete, let us look at what OpenAPI Generator produces from the Product schema in our specification above. Here is a simplified version of the generated PHP model:

<?php

declare(strict_types=1);

namespace App\ApiClient\Model;

class Product
{
    protected ?string $id = null;
    protected ?string $name = null;
    protected ?float $price = null;
    protected ?string $category = null;
    protected ?\DateTimeInterface $createdAt = null;

    /**
     * @param array<string, mixed> $data
     */
    public function __construct(array $data = [])
    {
        if (isset($data['id'])) {
            $this->id = $data['id'];
        }
        if (isset($data['name'])) {
            $this->name = $data['name'];
        }
        if (isset($data['price'])) {
            $this->price = (float) $data['price'];
        }
        if (isset($data['category'])) {
            $this->category = $data['category'];
        }
        if (isset($data['createdAt'])) {
            $this->createdAt = new \DateTimeImmutable($data['createdAt']);
        }
    }

    public function getId(): ?string
    {
        return $this->id;
    }

    public function getName(): ?string
    {
        return $this->name;
    }

    public function getPrice(): ?float
    {
        return $this->price;
    }

    public function getCategory(): ?string
    {
        return $this->category;
    }

    public function getCreatedAt(): ?\DateTimeInterface
    {
        return $this->createdAt;
    }

    /**
     * @return array<string, mixed>
     */
    public function jsonSerialize(): array
    {
        return array_filter([
            'id' => $this->id,
            'name' => $this->name,
            'price' => $this->price,
            'category' => $this->category,
            'createdAt' => $this->createdAt?->format('c'),
        ], fn($v) => $v !== null);
    }
}

You did not write any of that. The generator produced it directly from the schema. Every property has the correct type. The constructor handles deserialisation from JSON arrays. The jsonSerialize method handles the reverse. If you add a field to the specification and regenerate, the model updates automatically.

The same specification generates equivalent models in TypeScript:

export interface Product {
    id: string;
    name: string;
    price: number;
    category?: string;
    createdAt?: string;
}

export interface CreateProductRequest {
    name: string;
    price: number;
    category?: string;
}

And in Python:

# Python dataclass (simplified)
@dataclass
class Product:
    id: str
    name: str
    price: float
    category: Optional[str] = None
    created_at: Optional[datetime] = None

One specification. Three languages. All type-safe. All consistent.

PHP Code Generation: The Current Landscape

For PHP specifically, OpenAPI Generator offers three generator variants:

• php — the stable, battle-tested client generator producing PSR-compatible code with Guzzle as the default HTTP client
• php-nextgen (beta) — a modernised variant using newer PHP features and improved type handling
• php-dt (beta) — a data-transfer-focused variant

On the server side, generators exist for Laravel, Symfony, Slim, Mezzio (formerly Zend Expressive), Lumen, and Flight.

The PHP client generator supports extensive customisation through additional properties:

# Generate with custom namespace and Composer package name
openapi-generator-cli generate \
  -i api-spec.yaml \
  -g php \
  -o ./generated/php-client \
  --additional-properties=invokerPackage=Acme\\CatalogueClient \
  --additional-properties=composerPackageName=acme/catalogue-client \
  --additional-properties=phpVersion=8.2

The generated package includes a composer.json, proper PSR-4 autoloading, and is ready to be published as a private Composer package or included directly in your project.

Native PHP: lts/php-openapi-generator

The biggest practical annoyance with OpenAPI Generator is the Java dependency. It requires a JVM to run, which means either installing Java on your development machines and CI servers or using the Docker wrapper. For PHP teams, adding Java to the toolchain just to generate some PHP classes feels wrong.

lts/php-openapi-generator solves this. It is a native PHP code generator that produces PHP models and API clients directly from OpenAPI specifications, with no Java runtime required. Install it with Composer and run it like any other PHP tool.

The project is a hard fork of Jane PHP, which deserves full credit as the original foundation for PHP-native OpenAPI code generation. However, Jane has not kept pace with the spec: it still lacks OpenAPI 3.1 support despite 3.1 being the standard since 2021, and its PHP version requirements lag behind current releases. The lts/php-openapi-generator fork takes a different approach, targeting only the latest OpenAPI specification and the latest PHP version. It is not a gentle patch on top of Jane but a heavily updated codebase focused on staying current. Key improvements include:

• Full OpenAPI 3.1 support including type arrays (["string", "null"]), nullable types via type arrays, const values, and the $schema keyword
• PHP 8.4+ requirement taking advantage of modern language features
• Strict spec validation via lts/strict-openapi-validator built in
• PHPUnit 11 test suite

Usage is straightforward. Install, create a configuration file, and generate:

# Install the generator
composer require lts/php-openapi-generator

# Generate PHP models and API client from your spec
vendor/bin/jane-openapi generate --config-file .jane-openapi

The configuration file (.jane-openapi) is a PHP array pointing at your spec, namespace, and output directory:

<?php

return [
    'openapi-file' => __DIR__ . '/api-spec.yaml',
    'namespace'    => 'App\\ApiClient',
    'directory'    => __DIR__ . '/generated',
];

The generator produces typed PHP model classes and API client code from your specification. Because it runs natively in PHP, it integrates cleanly into existing Composer scripts and CI pipelines without any additional runtime dependencies. No Docker, no Java, no separate toolchain. Just PHP generating PHP.

Integrating Code Generation into CI/CD

Generating code once is useful. Generating it automatically on every spec change is transformational. Here is how to wire it into a CI pipeline:

# .github/workflows/generate-sdk.yml
name: Generate SDK

on:
  push:
    paths:
      - 'api-spec.yaml'

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate PHP Client
        uses: openapi-generators/openapitools-generator-action@v1
        with:
          generator: php
          openapi-file: api-spec.yaml
          command-args: |
            --additional-properties=invokerPackage=App\ApiClient

      - name: Generate TypeScript Client
        uses: openapi-generators/openapitools-generator-action@v1
        with:
          generator: typescript-axios
          openapi-file: api-spec.yaml

      - name: Commit generated code
        run: |
          git config user.name "SDK Bot"
          git add generated/
          git diff --staged --quiet || git commit -m "Regenerate SDKs from spec update"
          git push

Every time someone updates the API specification, the pipeline regenerates all client libraries and commits the changes. No manual steps. No drift between spec and code. The specification is the single source of truth, and the generated code follows it automatically.

Best Practices

Design-First vs Code-First

There are two schools of thought here, and I have a clear preference.

Design-first means writing the OpenAPI specification before you write any code. You design the API contract, get agreement from consumers, generate mock servers for frontend teams to build against, and then implement the backend to match the contract. This is the approach I recommend for any API that will have multiple consumers, and especially for public APIs.

Code-first means building the API in code and generating the specification from annotations or framework metadata. Libraries like swagger-php do this for PHP using attributes. The specification becomes a byproduct of the implementation. This works for internal APIs where you have tight control over both sides, but it tends to produce lower-quality specifications with missing descriptions and examples.

For code generation to work well, the specification needs to be detailed and accurate. Design-first naturally produces that level of quality because the spec is the primary artefact, not an afterthought.

Keep Specifications Up to Date

A stale specification is worse than no specification, because it actively misleads. If you take the design-first approach, the spec should be committed to source control and validated in CI. Tools like Spectral can lint your specification against style rules and best practices on every pull request. If you take the code-first approach, regenerate the spec on every build and fail the pipeline if the output differs from the committed version.

Customise the Generated Code

The default output from OpenAPI Generator is functional but generic. For production use, you will likely want to customise it. The generator supports Mustache templates that you can override to control the generated code style, add custom base classes, or integrate with your existing HTTP client setup.

# Use custom templates
openapi-generator-cli generate \
  -i api-spec.yaml \
  -g php \
  -o ./generated/php-client \
  -t ./openapi-templates/php

Store your custom templates in your repository alongside the specification. This way, regenerating the code always produces output that fits your project's conventions.

When to Use Generated Code vs Hand-Written

Generated code excels at the repetitive structural work: models, serialisation, HTTP transport, parameter handling. It is not the right tool for business logic, complex validation rules, or domain-specific behaviour. The sweet spot is to use generated code as a foundation layer — the plumbing — and build your application logic on top of it.

If you find yourself fighting the generator to produce code that matches your needs, that is a signal to either customise the templates or write that particular layer by hand. The goal is less boilerplate, not zero hand-written code.

Integrating with External APIs

One of the most immediately practical uses of OpenAPI is consuming third-party APIs. If an external service publishes an OpenAPI specification, and increasingly most do, you can generate a fully typed client library in minutes instead of spending days writing HTTP boilerplate by hand.

The workflow is straightforward:

1. Download the provider's OpenAPI specification (most publish it alongside their API docs)
2. Run it through OpenAPI Generator targeting your language
3. Install the generated package and start making type-safe API calls

# Grab the spec from the provider
curl -o payments-api.yaml https://api.payments-provider.com/v1/openapi.yaml

# Generate a PHP client
openapi-generator-cli generate \
  -i payments-api.yaml \
  -g php \
  -o ./generated/payments-client \
  --additional-properties=invokerPackage=App\\Payments

You now have a typed PHP client with proper models, authentication handling, and IDE autocompletion for every endpoint. No guessing at parameter names. No manually mapping JSON to arrays. No discovering at runtime that a field was renamed three versions ago.

When the Spec and Reality Diverge

Here is the problem nobody warns you about: external API specifications are often wrong. Not maliciously, but because keeping a specification perfectly in sync with a live API is hard, and most teams do not validate their own specs rigorously. You will encounter responses with extra fields not in the spec, missing fields that the spec says are required, types that do not match (a string where the spec says integer), and entire endpoints that behave differently from what is documented.

This is where strict validation tooling becomes essential. strict-openapi-validator is a PHP library designed for exactly this problem. It validates API requests and responses against an OpenAPI specification with zero tolerance for deviation. No type coercion, no silently ignoring extra fields, no glossing over missing required properties. If the data does not match the spec exactly, it tells you.

When integrating with external APIs, the validator's Client mode is particularly useful. It validates your outgoing requests strictly (catching your mistakes before they hit the wire) while validating incoming responses with warnings rather than hard failures. This is a pragmatic design choice: you control your requests, so those should be correct. But you do not control the external API's responses, and you do not want your application to crash because the provider's spec is slightly out of date.

<?php

declare(strict_types=1);

use LTS\StrictOpenApiValidator\Spec;
use LTS\StrictOpenApiValidator\Validator;
use LTS\StrictOpenApiValidator\ValidationMode;

// Load the provider's spec in Client mode
$spec = Spec::createFromFile(
    '/path/to/payments-api.yaml',
    ValidationMode::Client
);

// Validate your request before sending - strict, catches your errors
Validator::validateRequest($requestJson, $spec, '/v1/charges', 'POST');

// Validate the response - warnings only, so external inconsistencies
// are logged but do not break your application
Validator::validateResponse($responseJson, $spec, '/v1/charges', 'POST', 201);

The real value surfaces over time. When a provider updates their API and the responses start drifting from the published spec, the validator catches it immediately. Instead of discovering the mismatch weeks later through mysterious bugs in your application, you get clear, specific warnings telling you exactly which fields have changed and how. You can then raise the issue with the provider or adapt your code accordingly.

The error output is deliberately detailed. Each validation failure includes the JSONPath location of the problem, a reference to the relevant line in the specification, what was expected versus what was received, and a contextual hint for resolution. This makes it straightforward to figure out whether the problem is on your side or theirs.

Offering Your Own API for External Consumption

The other side of the coin is building an API that other teams or external consumers will integrate with. Here, the stakes are higher. Your specification is a public contract, and if your API does not match it, you are the one causing integration headaches for everyone downstream.

The design-first approach is strongly recommended for APIs you expose externally. Write the OpenAPI specification first, agree on it with your consumers, and then implement the backend to match. The specification becomes the source of truth, and you can generate SDKs for your consumers to use.

But writing a good spec and implementing it faithfully are two different problems. It is remarkably easy for implementation drift to creep in. A developer adds an extra field to a response that is not in the spec. A nullable field starts returning null when the spec says it is required. An error response uses a different structure than what is documented. Each of these is invisible to your test suite unless you are actively validating against the spec.

Strict Validation in Server Mode

This is where strict-openapi-validator in Server mode is invaluable. In this mode, the validator is uncompromising about your responses. Every response your API sends is validated against the specification, and any deviation throws an exception. It also validates the specification itself, catching structural issues in your spec before they reach consumers.

<?php

declare(strict_types=1);

use LTS\StrictOpenApiValidator\Spec;
use LTS\StrictOpenApiValidator\Validator;
use LTS\StrictOpenApiValidator\ValidationMode;

// Load your own spec in Server mode - maximum strictness on your responses
$spec = Spec::createFromFile(
    '/path/to/your-api-spec.yaml',
    ValidationMode::Server
);

// In your middleware or test suite:

// Validate incoming requests - provides public-safe error messages
// so clients get helpful feedback without leaking internal details
Validator::validateRequest($requestJson, $spec, '/v1/products', 'POST');

// Validate your own responses strictly - if this fails, your API
// is not honouring its contract and you need to fix it
Validator::validateResponse($responseJson, $spec, '/v1/products', 'POST', 201);

The strict typing enforcement is particularly important for APIs consumed across languages. If your spec says a field is an integer but your PHP code returns the string "123", a JavaScript client might not care, but a Go or Rust client will fail to deserialise. The validator catches this: string "123" is not integer 123, full stop. No type coercion, no silent conversion.

Integrating Validation into Your Development Workflow

The most effective approach is to run strict-openapi-validator in your test suite. Write integration tests that make real API requests and validate both the request and response against your spec. This catches drift the moment it happens, not after a consumer files a bug report.

<?php

declare(strict_types=1);

use LTS\StrictOpenApiValidator\Spec;
use LTS\StrictOpenApiValidator\Validator;
use LTS\StrictOpenApiValidator\ValidationMode;

final class ProductApiTest extends ApiTestCase
{
    private Spec $spec;

    protected function setUp(): void
    {
        parent::setUp();
        $this->spec = Spec::createFromFile(
            __DIR__ . '/../../api-spec.yaml',
            ValidationMode::Server
        );
    }

    public function testCreateProductMatchesSpec(): void
    {
        $requestBody = json_encode([
            'name' => 'Test Product',
            'price' => 29.99,
            'category' => 'electronics',
        ], JSON_THROW_ON_ERROR);

        // Validate request against spec
        Validator::validateRequest(
            $requestBody, $this->spec, '/v1/products', 'POST'
        );

        $response = $this->postJson('/v1/products', $requestBody);
        $response->assertStatus(201);

        // Validate response against spec - catches any drift
        Validator::validateResponse(
            $response->getContent(),
            $this->spec,
            '/v1/products',
            'POST',
            201
        );
    }
}

If your API returns a field that is not in the spec, the test fails. If it omits a required field, the test fails. If a type does not match exactly, the test fails. You find out in CI, not from an angry consumer.

The validator accumulates all errors before throwing, so you get the complete picture in one test run rather than fixing issues one at a time. And because the error output includes JSONPath locations and spec line references, you can pinpoint the exact source of the problem without digging through layers of code.

For PHP teams building APIs that others depend on, this combination of OpenAPI code generation and strict validation closes the loop. The specification defines the contract, code generation implements the boilerplate, and strict validation ensures the implementation matches the contract. No drift. No surprises. No "it works on my machine" when a consumer reports that your API returns something different from what the docs say.

The Bigger Picture

OpenAPI code generation is not just a convenience. It changes the development model. Instead of building clients by hand and hoping they stay in sync with the API, you have a single specification that drives everything: documentation, client SDKs, server stubs, request validation, mock servers, and contract tests. When the API changes, you update one YAML file and regenerate. Every consumer gets the update automatically.

For PHP teams in particular, this is a practical win. You can generate a type-safe client library for any third-party API that publishes an OpenAPI spec — and increasingly, most do. You can publish your own APIs with generated SDKs for every client team, whether they work in TypeScript, Python, Go, or anything else. And you can do it all from a single source of truth that lives in version control right next to your code.

The specification is the contract. The generated code is the implementation. Keep them in sync and you eliminate an entire class of integration bugs.