Status and the spec
Two endpoints need no authentication. One tells you the API is up; the other is the full contract as a machine-readable document.
Health
GET/v1/status
curl https://api.agentency.com/v1/status{
"object": "status",
"ok": true
}No key, no scope. Point an uptime monitor at it.
A 200 means the API is serving requests. It does not tell you that *your* key works, that you have credits, or that a background queue is keeping up. For those, use `GET /v1/me` and `GET /v1/usage` — both need a key, which is the point.
If you are debugging and GET /v1/status returns 404, the public API is
switched off for the deployment you are pointing at rather than broken.
The OpenAPI document
GET/v1/openapi.json
curl https://api.agentency.com/v1/openapi.json -o agentency.jsonAlso downloadable from /developers/openapi.json if you would rather not authenticate anything at all.
It is OpenAPI 3.1 and contains every path, parameter, request body, response
shape, the required scope per operation, and the webhook event payloads under
the top-level webhooks object.
It is generated from the running API, not maintained separately, so it cannot document an endpoint that does not exist or miss one that does. The reference pages on this site are rendered from the same file.
What to do with it
- Import it into Postman, Insomnia, Bruno or any OpenAPI 3.1 client to get a complete request collection.
- Generate a typed client for a language we do not ship an SDK for.
- Diff it between releases to see precisely what changed.
- Point contract tests at it so your integration fails loudly when a shape you depend on moves.
Both official SDKs are generated from this document, so a client you generate yourself is working from exactly the same source — not a copy that lags behind it.
What's next
- Versioning — how the contract changes over time.
- SDKs — clients we already generate.
- Support — when the health check is green and it still is not working.