Skip to main content
One credential integrates with this API: a tenant API key, sent as Authorization: Bearer vdx_live_…. It carries one customer and full access, and it is what every example in this documentation uses.
Every route here also answers a signed-in console session — the Vodex console is built on this same API. That cookie is not an integration credential: it carries a role an API key never has, it belongs to a browser rather than a server, and it is free to change without notice. Build against vdx_live_.

​
Getting a key

Mint one in the console under Settings → API keys. The plaintext is shown once, by the call that creates it, and no endpoint reads one back.
A lost key is replaced, not recovered. Keep keys server-side — a vdx_live_ key is full access to one customer’s telephony.

​
Roles

An API key carries the api role: it reaches every workspace resource an admin does, but it cannot manage people — invite, change a role, remove — or mint another key. Treat one as an admin credential. People in the console hold one role per workspace: A member asking for an agent it was not assigned gets 404, the same answer as an agent that does not exist.

​
Tenancy

There is no tenant parameter. Every tenant-scoped route derives its tenant from the credential and binds it for the whole request, so a caller cannot ask for another tenant’s data by changing a query string. An id that belongs to somebody else answers 404, never 403 — “no such call” is the only thing worth confirming. Do not read a 404 on a resource you believe exists as a bug report; read it as the id not being yours.

​
Errors