# `service_unavailable`: Dependency unavailable

> HTTP 503. A service this one operation depends on did not answer. The rest of the API is unaffected; retry this operation after `Retry-After`.

A few operations depend on a service outside Commune's own database, and this error means that service did not answer. Nothing was changed by the attempt, and every other operation keeps working, so back off on this operation only, not on the whole API.

The operations that can answer it are the event delivery ones (`GET /newsletters/{newsletter}/destinations`, `GET /newsletters/{newsletter}/delivery-attempts`, `GET /delivery-attempts/{attempt}`, `POST /delivery-attempts/{attempt}/replay` and `POST /newsletters/{newsletter}/portal-session`) and `POST /articles/{article}/test-send`, which hands the email to Commune's sending service.

It is never an empty answer in disguise: when the delivery service is down, you get this error rather than an empty list of destinations that would look like a newsletter with none.

## Why it happens, and how to fix it

### 1. The event delivery service is not answering

Destinations, delivery attempts and the delivery portal live in the event delivery service, and it did not respond.

**Fix:** Retry after `Retry-After` (10 seconds), with backoff if it repeats. Everything else in the API can be used in the meantime.

### 2. Event delivery is not available in this deployment

The deployment you are calling has no event delivery service configured. The message says it is not a transient failure, and there is no `Retry-After`, because waiting will not clear it.

**Fix:** Do not retry in a loop. It has been reported to Commune automatically; contact Commune with the `request_id` if it persists.

### 3. A test send could not be delivered

On `POST /articles/{article}/test-send`, Commune could not reach its sending service, or the sending provider refused every address in `to`. Nothing about the article changed.

**Fix:** Retry after `Retry-After` with the same `Idempotency-Key`. If the provider refused every address, check that the addresses in `to` are real, deliverable mailboxes before retrying.

## Retrying

Usually yes: retry the same request after `Retry-After`, except when the response has no `Retry-After`, which means the capability is not configured and will not come back on its own.

## Headers

- `Retry-After`: Seconds to wait before retrying (10). Absent when the capability is not configured at all, because retrying will not help.

## Example response

```json
{
  "error": {
    "code": "service_unavailable",
    "message": "Commune's event delivery service is not answering right now, so this operation cannot be served. Nothing was changed by the attempt, and no other operation is affected. Retry in a few seconds.",
    "request_id": "req_01j9c8h1q7m3n4p5r6s7t8u9v0",
    "docs_url": "https://usecommune.dev/errors/service_unavailable"
  }
}
```

Often confused with: [`internal_error`](https://usecommune.dev/errors/internal_error.md), [`rate_limited`](https://usecommune.dev/errors/rate_limited.md).