Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Exporting and Using the OpenAPI Specification

Exporting and Using the OpenAPI Specification

~13 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026

Swagger UI from chapter 6 only shows the OpenAPI specification interactively in the browser – often the RAW specification is needed as a FILE, e.g. for Postman import or auto-generated client SDKs.

Exporting the specification via the console

docker compose exec php bin/console api:openapi:export --output var/openapi.json

Produces a COMPLETE, static openapi.json file with ALL currently registered resources, operations, and schemas – EXACTLY the same content Swagger UI already loads in the background anyway.

YAML instead of JSON

docker compose exec php bin/console api:openapi:export --output var/openapi.yaml --yaml

SOME tools (e.g. certain CI pipelines or documentation generators) prefer YAML – the --yaml flag produces content that's IDENTICAL, just formatted differently.

Importing the specification into Postman

  1. Copy var/openapi.json out of the container: docker compose cp php:/app/var/openapi.json ./openapi.json
  2. In Postman: "Import" → select the file.
  3. Postman AUTOMATICALLY generates a complete collection with ALL endpoints, including example requests.

A REAL time-saver over manually typing out curl commands from the previous chapters – especially with LARGER APIs that have many resources.

Generating client SDKs (a preview)

Tools like openapi-generator-cli can generate TYPED TypeScript clients from EXACTLY this file – an approach we DELIBERATELY do NOT choose LATER (block 9), since hand-written axios calls stay more TRACEABLE for our project's scope, but it's worth KNOWING that this option exists.

Tipp: The exported file changes WITH EVERY adjustment to #[ApiResource] – a good HABITUAL check after larger changes: re-export and diff it against the previous version to catch UNINTENDED API changes early.