Support, status and security
How to reach us, what to include, and where to report a vulnerability.
Before you write
Two things make almost every question answerable in one reply:
The request_id. Every error carries one. It identifies the exact request in
our logs, which turns a support thread into a lookup.
{ "error": { "code": "provider_unavailable", "request_id": "req_8f14a2c9..." } }The call id, for anything about a specific call. With it we can read the compliance checks, the disposition and the timing; without it we are guessing from a description of what you heard.
Things you can answer yourself, faster
| Question | Where |
|---|---|
| "Why was this call blocked?" | GET /v1/compliance/evidence?e164=… — every check, with reasons |
| "Did my webhook get delivered?" | GET /v1/integrations/webhooks/deliveries |
| "What exactly did you send me?" | GET /v1/events/{id} — 30-day retention |
| "Why did this call cost that?" | GET /v1/wallet/transactions — one row per call |
| "Am I being rate limited?" | GET /v1/limits, and the RateLimit headers on every response |
Status
Incidents and planned maintenance are posted on the status page. If calls are failing and the status page is green, tell us — a quiet incident is worse than a loud one.
Checking the API yourself
Two unauthenticated endpoints, for your own monitoring. Neither counts against your rate limit and neither needs a key.
curl "$TONE_API/health" # liveness — the process is up
curl "$TONE_API/health/ready" # readiness — it can also reach its databaseGET /health answers 200 whenever the API is running. GET /health/ready
additionally checks the database and answers 503 when it cannot reach it —
which is the one to point an uptime monitor at, because a process that is up but
cannot read its own data will fail your requests while liveness still says
everything is fine.
Neither is a substitute for the status page: they tell you about the API, not about the carrier or the speech vendors your calls also depend on.
Talking to sales
Volume pricing, a negotiated per-minute rate, contracts and anything about
onboarding a large number of lines go through hello@usetone.ai, or the form
on the marketing site (POST /v1/contact-sales, which is what that form posts —
it takes no credential and is not something you need to integrate against).
Security
Report a vulnerability to hello@usetone.ai. Please include enough detail to reproduce it, and give us a chance to fix it before disclosing.
Things worth knowing when assessing us:
- Keys are shown once and stored hashed. A leaked key is revoked from the
dashboard with
DELETE /v1/api-keys/{id}, effective on the next request. Rotation (POST /v1/api-keys/{id}/roll) mints a replacement while the old one keeps working for a window you choose, down tonow. Both take a dashboard session rather than a key — a key can neither mint nor revoke credentials. - Scopes only ever narrow. A key cannot be widened after minting, and a key cannot mint another key.
- Tenant isolation is enforced in the database, not in application code, and an unscoped read returns nothing rather than someone else's data.
- Secrets are write-only. There is no read-back path for a stored credential, which is why tool and endpoint credentials are referenced by id rather than written inline.
- Webhook payloads are signed over the raw body — see Webhooks.
What we will not do
We will not tell you a compliance question is legally settled. Tone runs the TRAI checks and keeps the evidence that you ran them; TCCCPR liability stays with the sender. On anything that turns on your specific obligations, we will tell you what the product does and recommend you ask your own counsel.