DocumentationTry Hanzo
API

One API for models, agents and tools

Every Hanzo capability answers under one base URL, behind one key. There is no per-service host to look up and no second version to migrate to later.

Base URL

https://api.hanzo.ai/v1

Authenticate with a bearer token: Authorization: Bearer <your key>. Keys are created and revoked in the console, and revoking one there is what stops it working.

Every route lives under /v1, and every service answers on the same host — there is no second base URL to configure and no v2 waiting to break the first one. Rate limits are applied per caller and across the edge as a whole; a rejected request comes back as a 429 with a Retry-After rather than a dropped connection.

Core endpoints

A few of the ones people reach for first. Every parameter and error shape is in the reference.

/v1/chat/completionsPOST
A completion from any model your organization can reach, streamed or buffered. Model ids come from the catalog, so the list is a request rather than a page in the docs.
/v1/modelsGET
What your organization may call right now — the models we serve plus any provider account you have connected, with their identifiers.
/v1/embeddingsPOST
Vectors for search, retrieval and clustering, from the same key and the same bill as generation.
/v1/agentsGET · POST
Define an agent once, run it by reference, and read its runs afterwards. The definition lives here, so everything that runs it runs the same one.
/v1/billing/balance · /v1/billing/usageGET
What is left, and what was spent. Usage is recorded per call and attributed to the organization on the token, so a bill can be traced back to the request that caused it.
/v1/toolsGET
The tools your organization can call. An agent picks from this list, and so can you — it is the same catalog either way.

How it fits together

One key, one bill
A single key authenticates every endpoint, and usage meters to the organization it belongs to. Spend is attributed in one place instead of once per service.
Identity is the gateway’s to state
Every request passes a gateway that throws away the identity headers a client sent and writes them again from the verified token. Nothing downstream has to wonder whether an org id came from a token or from a curl flag.
Generated, not hand-written
The clients come from the OpenAPI document this API serves, and their method names are its operation ids. A client is checkable against a release rather than against somebody’s memory.