Delivery
Errors & retries
What each HTTP error means, how failed deliveries are retried, and which failures raise an alert.
HTTP errors
| Status | Meaning |
|---|---|
400 |
Validation details, unknown tenant, bad channel/kind pairing, bad updated_since. |
401 |
Missing or invalid token. |
403 |
Authenticated, but not with a client-credentials token (v2). |
413 |
Request body over 5 MB (v2 sends). |
429 |
Tenant or client daily quota reached. |
The retry ladder
A delivery that fails for a transient reason is retried automatically: 5
attempts in total, roughly 60s, 120s, 240s, then 480s apart, before it is
marked failed. Rate-limit waits never use up attempts: waiting for your
own per-minute window is not a failure.
A permanent rejection fails at once with its reason on the delivery
(last_error), without using the ladder:
SMS (Beem)
Bad credentials (100), unregistered source (101), bad body (103), no balance (104), unapproved sender (105), and bad destination (102: one wrong number, never an outage).
An expired token (190) and paused or disabled templates (132015, 132016). Other bad requests are likewise permanent.
A refused recipient, failed SMTP authentication, or an empty body.
Push
No registered devices for the user, a project-level refusal, or every token rejected.
Service alerts
Outages email your team
Repeated channel-wide failures, such as a suspended WhatsApp token, an empty Beem balance or a wrong SMTP password, raise a service alert and email your client admin and tenant contacts. When the failures stop, a recovery notice closes the loop. Per-recipient failures (one bad address, one dead token) never page anyone.