The short answer
Call get_email_delivery_status with either (entity_type, entity_id) or a provider message_id, then read the recipients array.
{
"entity_type": "invoice",
"entity_id": "the invoice's uuid"
}
You get a per-recipient roll-up alongside the raw event timeline:
{
"summary": "delivered",
"recipient_count": 2,
"delivered_count": 2,
"failed_count": 0,
"keyed_by": "entity",
"recipients": [
{
"recipient_email": "accounts@example.com",
"message_id": "...",
"latest_event": "delivered",
"sent_at": "...",
"delivered_at": "...",
"bounced_at": null,
"complained_at": null,
"reached": true
}
],
"timeline": []
}
Why does recipients matter more than summary?
An invoice, statement or work order can go to several people at once. Every contact across the client's sites flagged to receive that document type is included, de-duplicated by email address.
The platform dispatches one message per recipient, each with its own provider message id. A send to two contacts is two messages, two delivery records, two independent outcomes. One can arrive while the other bounces.
So the fields that answer the real question are:
recipient_count— how many distinct addresses this send reached out todelivered_count— how many are confirmed delivered and not later bounced or complainedfailed_count— how many bounced or reported it as spamreached— per person, the plain yes or no
summary reports the worst outcome across all recipients. If one person out of three bounced, the summary reads bounced. A failure on any recipient can never hide behind somebody else's successful delivery.
Where does the evidence come from?
The delivery records are written by the email provider's webhook, not by the code that sent the message. They are an independent account of what happened on the wire — sent, delivered, delivery_delayed, bounced, complained — each stamped with the recipient address and the time it occurred.
That is the difference between "our system believes it sent an email" and "the provider confirms it was delivered to this address at this time". When a client says an invoice never arrived, only the second one settles it.
What does keyed_by tell me?
How complete the answer is:
"entity"— every recipient of every send for that entity. Complete."message_id"— only the one message you asked about. It may omit other recipients of the same send.
Prefer (entity_type, entity_id) whenever you have them. A lookup by single message id answers a narrower question than most people intend to ask, and on a multi-recipient send it will under-report.
What about a bounce?
A bounce means that address rejected the message. Check for a typo first, then confirm the address with the client.
One caution: a bounce can be temporary — the receiving mail server was down or refusing connections for a while. A temporary failure does not mean the mailbox is dead, and deleting a valid billing address over one is an expensive mistake. The platform distinguishes permanent from transient failures and tells you which you are looking at.
Can I see this without calling a tool?
Yes. Entity detail pages carry an inline delivery badge backed by the same resolver, so the screen and the agent tool cannot disagree about whether a client was emailed. If you are already looking at the invoice or proposal, the badge is the faster route.