Generating an OpenAPI Specification
OpenAPI is the standard way to describe a REST API in machine-readable form. The platform generates one from your own configuration.
Where to find it
Architect Panel → Integration & Connections:
- OpenAPI Specification — generate and download the spec
- API Server — the API itself and its settings
- API Clients — who may call it, and with what rights
Why generate rather than write
A hand-written specification is accurate on the day it is written. A generated one reflects what the API actually exposes, which is what a consumer needs. It also cannot drift, because there is nothing to keep in step.
What a consumer gets
Client libraries generated in their own language, request validation, and API tooling that works without anyone reading prose. For an integration partner this is the difference between a day and a fortnight.
It only describes what you exposed
The generator works from the datastores marked as exposed, so the specification is a description of a decision you already made rather than a new exposure. If something is missing from the spec, the question is whether it should be exposed at all.
Regenerate after changes
Add a field or a datastore and the specification is out of date until regenerated. Make it part of your release routine, and hand consumers the new spec when the API changes rather than letting them discover it.
Versioning
Consumers build against a version. Removing a field or changing a type breaks them silently, and they will find out in production. Treat the published specification as a contract: add freely, change carefully, remove only with notice.