Status and service availability
This page explains how to tell whether a problem is on your side or ours, how the API reports temporary unavailability and how to get help. RelationsAI does not publish a public status page for the API preview; the API itself tells you when it is temporarily unavailable, and support is by email.
Check the API from your side
GET/workspace is the best health check: it is a cheap read, needs only the scope every key has, and exercises authentication, your workspace and the API in one request. Look at the status code and the X-Request-Id response header (add -i to cURL to print the headers).
| What you see | What it means |
|---|---|
200 with an X-Request-Id | The API is reachable and your key works. |
401 or 403 with an error code | The API is up; the problem is the key or the workspace. See Authentication. |
429 | The API is up; you are over a limit. See Rate limits. |
503 service_unavailable with Retry-After | Temporarily unavailable on our side. Retry after the delay. |
500 internal_error | An unexpected error on our side. It is not stored under an Idempotency-Key, so a retry runs the request again. Retry reads with backoff; for a write, check whether the change was applied first, then retry with the same key only if it was not. |
| No response, a timeout, a TLS or DNS error, or an error page that is not JSON | The request did not reach the API, or the answer did not reach you. Check your network, proxy and DNS first; then check whether a write already happened before sending it again (or retry with the same Idempotency-Key, if you sent one). |
Every answer that comes from the API carries an X-Request-Id header and, for errors, the JSON error envelope. An answer without them did not come from the API.
Temporary unavailability
When a service the API depends on is briefly unavailable (for example during maintenance or a deploy), the API answers service_unavailable (503) with a Retry-After header. The API fails closed: it refuses the request before doing anything rather than skipping a check, so nothing was created, dialled or charged.
- Wait
Retry-Afterseconds and send the request again: nothing was done the first time. - Back off further if it repeats, and alert a person if it lasts more than a few minutes.
- Do not switch to new idempotency keys or replay old work: once the API answers again, retries with the original keys complete each operation exactly once.
Calls and campaigns that were already running continue independently of your API requests. Read their state once the API answers again; webhook deliveries that failed in the meantime are retried on their schedule.
Incidents
If errors persist for more than a few minutes, email support@relationsai.com with:
- the request ids (
X-Request-Id) of a few failing requests; - when they happened, in UTC (for example
2026-10-21T09:30:12Z); - the operations, the HTTP statuses and the error codes;
- whether it affects test mode, live mode or both.
Never send API keys or full Authorization headers, webhook signing secrets, recording links, customer personal data (names, phone numbers, contact details) or transcripts, recordings and analysis of real calls; send ids (key_..., call_...) instead. See Support for everything to include. There is no phone line or chat, and no response-time commitment is published for the preview.