Delivery evidence
Delivery evidence
What provider acceptance, terminal callbacks, and authenticated device evidence prove for each notification channel.
WarnFire distinguishes a notification request, provider acceptance, and terminal evidence. Accepted confirms that a provider took responsibility for the request. It does not prove that a device, inbox, or person received it.
The Delivery Activity page is the source for workspace-scoped delivery history. It includes the incident, responder, channel, current outcome, and the strongest durable evidence WarnFire has received. A specific provider name is shown on the row for SMS; the other channels record their evidence without a per-row provider label.
Evidence by channel
| Channel | Provider handoff | Stronger terminal evidence | Important limitation |
|---|---|---|---|
| SMTP/SES accepted | Signed SES delivery, bounce, or complaint callback | Open and click are engagement signals, not proof that a person understood or acted | |
| SMS | Twilio or Telnyx accepted | Provider delivery receipt: delivered, failed, or unconfirmed | Carrier delivery does not prove the intended person read the message |
| Voice | Provider accepted the call request | Answered, completed, or failed callback | Answered does not prove the intended responder heard or understood the call |
| Push | APNs accepted | Authenticated app evidence: received or opened | Apple does not provide a general server-side handset-delivery callback |
Outcome meanings
- Requested
- WarnFire created the notification attempt and handed it to the channel’s delivery path. It is the starting outcome before a provider responds.
- Provider accepted
- The provider accepted WarnFire’s request. WarnFire may still be waiting for a terminal result.
- Delivered
- A terminal provider callback confirmed delivery, or an authenticated device reported that it received the push notification. Device receipt of a push is shown as Delivered; there is no separate “received” outcome.
- Opened
- The authenticated mobile app reported that the user opened the notification and its incident target.
- Failed
- A provider callback or internal terminal state reported a non-delivery result such as failed, undelivered, canceled, bounced, or complained.
An accepted attempt can remain accepted while WarnFire waits for stronger evidence. It must not be interpreted as verified delivery.
Push evidence is device-specific
WarnFire registers each signed-in mobile device separately. Delivery Activity can therefore show receipt or open evidence for an iPhone and an iPad as separate rows. Signing out revokes that device’s registration without signing out other devices for the same responder.
iOS may delay or omit background execution in some power, network, and device states. A missing app-received event is not by itself proof that APNs failed to display a notification. Opening the notification produces stronger authenticated evidence when the app can report it.
Callback integrity and retries
WarnFire verifies signed provider callbacks where the provider supports signatures and correlates them to the original durable delivery attempt. Callback processing is idempotent because providers can retry the same event. The recorded provider identifier and attempt identifier allow terminal results to arrive after the initial request transaction.
Delivery history does not expose full destination addresses or phone numbers in aggregate reporting. Use incident-level evidence when responder-specific audit detail is required.
Review delivery records
Follow Find a delivery attempt to filter attempts, trace a test page, and interpret an accepted, delivered, opened, pending, or failed outcome without overstating what the evidence proves.