Every contract-based REST endpoint in Acumatica can produce its own OpenAPI (Swagger) document, generated live from the actual contract — the fields, entities, and actions you've configured — rather than hand-maintained separately. That's the single biggest practical advantage REST has over the older SOAP API, which has no equivalent.
Where the spec comes from
The Swagger document is generated per endpoint and version, reflecting exactly what that contract exposes — not a generic schema for "Acumatica" as a whole. Because it's derived straight from the endpoint configuration, it stays accurate as you add custom fields or clone a new endpoint version; there's no separate spec file to hand-edit and let drift out of sync with the real contract.
Fetching the document
GET /entity/Default/24.200.001/swagger.json HTTP/1.1
Host: yourinstance.acumatica.com
Authorization: Bearer {access_token}The returned document is a standard OpenAPI/Swagger JSON file — the same format tooling across the ecosystem already understands, which is what makes it useful rather than a curiosity.
What it's actually good for
Three uses cover almost every reason to pull it: generating a typed client (a C# or TypeScript SDK) instead of hand-writing request/response classes for every entity you touch; feeding it into an interactive API explorer (Swagger UI, Postman's OpenAPI import) so a developer can browse and test the exact live contract instead of guessing field names from a screen; and diffing it against a previous version's spec to see precisely what changed during a contract or platform upgrade, which is far more reliable than reading prose release notes.
A typed client generated from the spec is a snapshot, not a live binding. If you add a field to the endpoint or bump its version, regenerate the client — a stale generated model silently ignoring a new field is a common and avoidable source of "the data's there in Acumatica but my integration doesn't see it" bugs.
Known rough edges
Generated specs from screen-derived contracts don't always produce the cleanest OpenAPI output — deeply nested detail structures (order lines, tax details) can generate verbose or awkward-to-consume schemas compared to a hand-designed API, and some code generators handle Acumatica's polymorphic-looking action definitions better than others. Test-generate a client against a small entity first before committing to a code-generation pipeline for your whole integration.
Wrapping up
The per-endpoint Swagger document is generated from the live contract, which makes it the most reliable single source of truth for what an Acumatica REST endpoint actually exposes — more reliable than a screen, and more reliable than a teammate's memory of what a field is called. Use it for client generation and version diffing, and regenerate whenever the endpoint's contract changes.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.