> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aciona.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhook responses

> HTTP codes returned by the ingestion endpoint and what to do about each one.

Every source uses the same ingestion endpoint and the same response codes.

```bash theme={null}
POST https://ingress.aciona.me/webhooks/<alertSourceId>
X-Aciona-Token: <sourceToken>
```

## Codes

| Code  | Meaning                                                  | What to do                                           |
| ----- | -------------------------------------------------------- | ---------------------------------------------------- |
| `202` | Alert accepted and recorded. Processing is asynchronous. | Nothing. Confirm the incident in the dashboard.      |
| `400` | Invalid payload or missing required fields.              | Validate the JSON rendered by the tool's template.   |
| `401` | Token missing, invalid, or from another source.          | Check the `X-Aciona-Token` header; rotate if needed. |
| `403` | Alert source inactive.                                   | Re-activate the source under **Alert sources**.      |
| `404` | Source identifier does not exist.                        | Check the full URL.                                  |
| `413` | Body above the limit (1 MB by default).                  | Trim the fields sent in the template.                |
| `429` | Request volume above what is accepted.                   | Group alerts at the source before sending.           |
| `5xx` | Error on the aciona.me side.                             | Let the tool retry; if it persists, contact support. |

## What is persisted in each case

<Note>
  Requests rejected with `400`, `401`, `403`, `404` and `413` **persist nothing**. There is no alert record to inspect afterwards — if you need a trail, look at the originating tool's log.
</Note>

A `202` means the alert was recorded. It may then:

* Create an incident;
* Be **aggregated** into an open incident;
* **Resolve** an open incident (sources with auto-resolution);
* Be discarded, when the state sent is not actionable.

See [Alert without incident](/en/troubleshooting/alert-without-incident).

## Retry behavior per tool

| Tool                    | Retries on                                                       |
| ----------------------- | ---------------------------------------------------------------- |
| Datadog                 | `5xx` only                                                       |
| New Relic               | Consecutive errors can put the destination into automatic snooze |
| Alertmanager            | Re-sends on the next `repeat_interval`                           |
| Grafana                 | According to the notification policy                             |
| Zabbix                  | According to the media type's retry configuration                |
| CloudWatch (via Lambda) | According to the function's retry configuration                  |

<Warning>
  `4xx` errors are normally **not re-sent**. A wrong token means lost alerts until someone fixes the configuration — it is worth monitoring delivery failures on the tool's side.
</Warning>