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 is never a viewer: it carries the api role and can do anything an owner can, so treat one as an owner credential. (Roles proper — owner, admin, viewer — apply to people in the console, where a viewer may read but not write.)

​
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