The reason the response cannot promise more is structural. The send endpoint hands your message to a separate delivery pipeline that WhatsApp does not fully control: the recipient's device has to be reachable, it has to accept the message, and the path runs over infrastructure outside WhatsApp's servers, according to the dev.to write-up [16]. A queue in front of that can only tell you it took the job.
Count the states and the gap has a size. The sequence names four [1][2][4][5][6]. The HTTP response reports the first [8]. That leaves three that exist only as asynchronous events fired after the call has already returned [1][7]. The ordering matters as much as the count: accepted sits before sent, so a 200 does not establish that the message left Meta's infrastructure at all [3][4]. The one status you get synchronously is the one that promises the least.
Wiring up the webhook endpoint is the easy half. The status events are keyed to the message ID returned by the send call [10], which makes that ID schema rather than a log line. If the outbound row does not store it, or the handler cannot match an incoming status back to a row, you have no delivery visibility regardless of what the send responses said [11][15]. Persisting a message ID in a log file you grep is not reconciliation.
Two states I would not build an alert on as-is. Read is gated on the recipient's read receipts, which the post notes are commonly disabled and outside your control [6], so a missing-read alarm measures privacy settings alongside reachability. And a free-form send after the 24-hour customer service window closes is not a transport failure [13]. The post's argument is that a closed window looks a lot like a generic delivery failure, and the actual cause is easy to lose in the noise [17]. That pushes window state into your own store: last inbound timestamp per contact, checked before the send, template path otherwise [13].
For any of this to hurt, only one condition has to hold, and it usually does: some downstream step, or a human reading a dashboard, treats your "sent" flag as arrival. The write-up calls that the single most common mistake in WhatsApp automation code, and the reason it is easy to make is that the request looks successful in every way the code checks [9]. Nothing throws.
The fix is that the outbound record stays pending until a webhook resolves it [11]. That is a migration and a new endpoint, not a monitoring tweak, which is why it tends to get deferred until a customer reports the silence.
