On this page
In short#
One set of rules for the APIs providers publish on API360 and for the platform's own domain APIs. Each page states one rule family, shows the shape on the wire and names the lint rules that check it. The rules run as a Spectral ruleset, so a specification is checked the same way on a laptop, in a pipeline and in Studio.
| Page | Rule family | What it fixes |
|---|---|---|
| Naming | snake_case names | Property, query parameter and enum value names, and path segments |
| Errors | one error envelope | The body, the status codes and the retry headers of an error |
| Pagination | page, per_page | Parameters, the maximum of 100 and the total in the body |
| Idempotency | Idempotency-Key | Safe retries of a POST that creates a resource |
| Versioning | major version in the path | Where the version lives and what changes it |
| Deprecation | Deprecation and Sunset | How a retiring operation announces itself |
| Security | a requirement on every operation | Credentials in headers, never in the URL |
| Linting a specification | the ruleset | How to run it, its two profiles and the allow-list |
Who the rules are for#
- A provider designs a product API against the rules and lints its OpenAPI file before publishing.
- The platform lints its own 13 domain specifications against the same rules, with a dated list of the findings it still carries.
- A consumer reads the same pages to know what to expect from any product: the same error body, the same paging, the same retry rules.
Planned
Studio runs the provider profile of the ruleset on every specification a provider uploads and shows the findings next to the file.
Related#
- Errors, status codes and retries: what a consumer sees today.
- Versions and breaking changes: the written definition of a breaking change.
- For providers: publishing and versioning a product.
Updated 2026-10-17