Skip to main content
Every message Boom sends or receives leaves a row with its delivery status and, when something went wrong, the reason. It is the same log the app shows under Settings → Logs, available to an agent or a script so you can review delivery in bulk instead of opening conversations one at a time. Typical questions it answers: which numbers never received this week’s send, who has blocked us, and whether a specific customer got their message.

​
Statuses are a lifecycle, not a verdict

SENT, DELIVERED and READ all mean the message went out. They differ only in how far it got:
To count what you sent, ask for SENT, DELIVERED and READ together. Asking for SENT alone returns only the ones still unconfirmed, which on a healthy account is a small fraction of what actually went out.
How far a message can get depends on the channel. WhatsApp reaches READ. Email never does — there is no read receipt, so an email resting at DELIVERED is fully settled. And PENDING on an inbound message is normal and permanent: nobody sends a receipt for a message a customer wrote to you.

​
Why a message failed

On email, errorMessage carries the reason in words. On WhatsApp you usually get a numeric errorCode instead: Any other code is passed through unchanged. Rows sent before codes were recorded have neither field; that is expected, not a data error.

​
Filtering

To filter on several statuses or channels over HTTP, pass them as one comma-separated value (?status=SENT,DELIVERED,READ). Repeating the parameter (?status=SENT&status=DELIVERED) keeps only the last one and answers 200 with a narrower filter than you asked for.
direction defaults to OUTBOUND — a delivery status only means something for a message you sent. Pass direction=INBOUND for what customers sent you.

​
The window, and how to widen it

With no dates, the read covers the last seven days — a rolling window from the moment you ask, so the edge is a timestamp rather than a midnight. Every response says which window it used:
Quote that range alongside any count you report — “48 failures” means something different over a week than over a year. The default is not a ceiling. Name createdAfter, createdBefore, or both, and that window is honoured however wide it is. Naming either one turns the default off entirely, so createdBefore=2026-08-01 really does mean everything before August. A bare date means the whole day, in UTC. createdBefore=2026-09-30 includes everything that happened on the 30th, not just the instant it began — so createdAfter=2026-09-01&createdBefore=2026-09-30 is the whole of that range, with no missing final day. Pass a full timestamp (2026-09-30T06:00:00Z) when you want an exact instant; it is used as given. Once you start paging, the window is fixed. A next_cursor carries the range its first page resolved, so range is identical on every page of one result set even though the default floor is relative to “now”.
There is no total. Results page through next_cursor, and a page comes back without counting the rows behind it — counting an unbounded log is far more expensive than reading a page of it. To total something up, page to the end.

​
What this log does not cover

It lists messages, so it is not a delivery-rate report. A few send failures never create a row at all — an absent message is not proof that nothing was attempted. Message text is never returned; the log answers what happened to a message, not what it said.