Webhook responses - aciona.me

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

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) or more than 100 alerts in a single request.	Trim the fields sent in the template, or split the batch into smaller requests.
`429`	Volume above what is accepted for the source (default: 600 alerts per minute per source) or too many attempts with an invalid token.	Honor the `Retry-After` header and group alerts at the source before sending.
`5xx`	Error on the aciona.me side.	Let the tool retry; if it persists, contact support.

Ingestion limits

Limit	Default	Response when exceeded
Body size	1 MB	`413`
Alerts per request	100	`413`, with `code: "too_many_alerts"`
Alerts per minute, per source	600	`429`, with `code: "quota_exceeded"` and a `Retry-After` header (seconds)

The per-minute limit is per alert source: one very noisy source does not eat into the quota of the organization’s other sources. If a tool sends large batches often (for example, an Alertmanager grouping many alerts), adjust grouping at the source.

What is persisted in each case

Requests rejected with 400, 401, 403, 404, 413 and 429 persist nothing — not even part of the batch. There is no alert record to inspect afterwards — if you need a trail, look at the originating tool’s log.

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.

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

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.

​Codes

​Ingestion limits

​What is persisted in each case

​Retry behavior per tool

Codes

Ingestion limits

What is persisted in each case

Retry behavior per tool