Authentication
Every /v1/* request needs a Devotel API key in the Authorization header:
Authorization: Bearer dvt-...Key format
dvt- followed by 40 lowercase hex characters, for example
dvt-91159742a1b2c3d4e5f60718293a4b5c6d7e8f90. Malformed keys are rejected before any lookup, so a
typo comes back as invalid_api_key rather than a slow failure.
How keys are stored
Only sha256(key) and the first 8 characters are stored. The dashboard shows you dvt-9115… for
identification; the full value exists exactly once, in the dialog that created it.
Lost a key? Revoke it and create a new one — it cannot be recovered or resent.
Managing keys
At chat.devotel.com/keys you can create keys, see each one’s prefix, creation date, last use and rate limits, and revoke any of them. Revocation takes effect immediately — the gateway drops its cached copy of the key as part of revoking it.
A revoked key returns 403 with code key_revoked, which is distinct from 401
invalid_api_key. That difference is deliberate: 403 means “this key existed and no longer
works”, so your retry logic can stop rather than assume a transient failure.
Keeping keys safe
- Keys carry full access to your account’s API usage and are billed to you. Treat them like passwords.
- Never put a key in browser or mobile code. Anything shipped to a user’s device is readable by that user. Call the API from your own server and keep the key in its environment.
- Use one key per application or environment. Then revoking a leaked key affects one thing.
- Rotate by creating the new key, deploying it, and revoking the old one — in that order.
Errors
| Status | code | Meaning |
|---|---|---|
| 401 | missing_api_key | No Authorization header, or not Bearer |
| 401 | invalid_api_key | Malformed key, or no such key |
| 403 | key_revoked | The key exists but has been revoked |
Full reference: Rate Limits & Errors.