# internal_error

- HTTP status: 500
- Retry: Yes, with backoff
- Execution: may have started
- Admin needed: no

**Internal error.** An unexpected error. A 500 is never stored: a retry runs the request again from the start (with or without the same Idempotency-Key); it does not replay an earlier result. A read can simply be retried. For a write, the API does not know whether the change was applied before the error, so read the resource first (for a call, list calls filtered by `to` and `created_after`; for a campaign or a contact, retrieve it) and retry only if the change is not there.

## What it means

The API returns HTTP 500 with `error.code` set to `internal_error`. The default message is: "Something went wrong on our side."

## Common causes

- An unexpected server fault.

## How to identify it

Check the response status (`500`) and `error.code` (`internal_error`). Branch on `error.code`, not on the message text: messages can be reworded, codes do not change within v1. Log `error.request_id` (also sent as the `X-Request-Id` header) so support can find the request.

## How to fix it

- For a read: retry with exponential backoff.
- For a write: read the resource state first, then, only if the change did not happen, retry (with the same Idempotency-Key if you sent one; a retry without a key is a new request).

## Retry guidance

Use exponential backoff (for example 1 s, 2 s, 4 s, up to about a minute). For a write, read the resource first to find out whether the change was applied before you send anything again.

## Did anything happen?

The work may have started before this error was returned. Do not assume nothing happened: read the resource (for a call, list calls filtered by `to` and `created_after`; for a campaign, retrieve it) before you send anything again. A charge may have been recorded for work that started; check the call or campaign before you act.

## Idempotency

Nothing is stored after a 500, key or no key: a retry runs the request again (it is not a replay), so a blind retry of a write can repeat it. Check the state of a write first with a GET; retry only if it did not happen (with the same key if you sent one).

## Who can fix it

The developer who sends the request can fix it; no administrator action is normally needed.

## When to contact support

If it persists, write to [support@relationsai.com](mailto:support@relationsai.com) with the request_id. See [Support](/resources/support) for what to include (the `request_id`, the time in UTC, the operation, and whether you used a test or live key) and what never to send (API keys, Authorization headers, webhook signing secrets, recording links, transcripts or customer data).

## Example error response

```json
{
  "error": {
    "code": "internal_error",
    "message": "Something went wrong on our side.",
    "details": {},
    "request_id": "req_r3hmr3ccufgy43lrd5ssiycn",
    "retry": "yes",
    "doc_url": "https://docs.relationsai.com/errors/internal_error"
  }
}
```

See all codes in the [error-code reference](/fundamentals/error-codes).