Webhooks for pre-delivery send failures + longer transient retries

Released: August 9, 2026

Pre-delivery failures now emit message.status Added

Some outbound sends fail before Meta ever admits the message — a transient Meta outage (error 131000), a quota/entitlement refusal, an account cooldown, or a compliance block. Meta issues no wamid and sends no status webhook for these, so previously the only way to learn about them was to poll GET /v1/messages/{id}. A webhook consumer would see the send accepted and never hear that it failed.

message.status now synthesizes a failed event for these cases, so you get the same push signal you already get for a Meta-emitted failure. Two differences to code for:

• statuses[0].id is the Kirimdev msg_… id, not a wamid.… — none exists. It equals the id returned by your original send call, so correlation is direct.
• errors[0].code is Meta’s integer code when the failure came back from Meta (e.g. 131000); for a Kirimdev-side refusal it is the sentinel -1. Map either to a stable Kirimdev code via the error catalogue.

Note

Nothing changes for failures Meta itself reports post-admission (a real wamid that later fails) — those still arrive as the verbatim Meta passthrough they always did.

Longer retries for transient Meta failures Changed

Transient Meta errors like 131000 (“Something went wrong”) are often a brief server-side blip that clears in minutes. They previously exhausted their retries within seconds and surfaced as a permanent failure. They now retry on a longer schedule — roughly 1 min → 2 min → 4 min → 8 min (about a 15-minute window) — before the terminal failed event fires, so a short Meta outage resolves itself instead of stranding the message.

Webhook event reference → Handling failed sends