How to check notification delivery and resend it
Find a notification in Deliveries, review the sending result, and queue another delivery of the same event if needed.
Updated:
If an event has already appeared in Cryptanio but the message has not arrived, open “Deliveries”: it shows the channel, attempts, and sending result. You can resend a completed delivery. This creates a new delivery record for the same event; the original stays in the history. It does not create a new transfer or blockchain event.
Consider a shop server that temporarily stopped accepting webhooks and has now recovered. You need to find the failed delivery and send the notification again. The same checks apply to a messenger notification, although a successful send does not prove that a person has read the message.
What you need
You need access to the correct account and project. A member with read access can view the history; resending requires permission to change data. Have the event time, project, and channel ready. For a webhook, the event_id from your application log is useful. It identifies an event, not a transfer TXID.
If the channel is not connected yet, first follow the relevant guide: Telegram, Discord, or Slack. This guide checks delivery that has already been configured.
1. Find the event first
Open “Events” and make sure the required transfer is recorded in the expected project. Compare the network, address, asset, direction, and transaction identifier. A detected incoming transfer and a confirmed incoming transfer are different states that can have separate notifications.
If the event is missing, resending a delivery will not recover it from the blockchain. Check the monitoring rules and activity, service status, and selected project. The multiple-wallet guide explains how to connect addresses.
2. Find the relevant record in Deliveries
Open “Deliveries”. Select “Channel” and “Project”, and set “From date” if needed. If you know the exact event_id, enter it in “Event ID”. Click “Apply filters”. In a project-specific view, the project scope is already set.
Check the record’s state: “In flight”, “Failed”, or “Delivered”. Click “Open” to see “Delivery details”: the attempt count, “Last response”, queue time, and completion time. If there is an error, its description is available. The same event ID can have several deliveries to different channels.
The absence of an HTTP code does not by itself prove a failure: the result depends on the channel. For a webhook, compare the response with your server log. The destination field may be protected and may not show the full address containing a secret.
3. Fix the cause before resending
Check that the handler is available and that the app has the required permissions or access to the channel. For a messenger, check whether the connection or route is paused; if authorization has been revoked, use “Reconnect” where that button is available. A connection test sends a separate service message; it does not replay the selected payment.
For a webhook, make sure the handler verifies signatures and correctly stores accepted events. See the automatic order-confirmation guide for details. Resending does not fix a bug in the receiver’s code.
4. Queue another delivery
Click “Resend” beside a completed record. In the “Resend notification?” dialog, confirm with “Queue another delivery”. Resending is unavailable while the record is “In flight”: wait for the current delivery rather than creating competing sends.
Cryptanio creates a new delivery ID while keeping the original event ID and its saved content. The original record and its result are not overwritten. You can also repeat a successful delivery, so this action can create a duplicate for the recipient. One-time emails containing access links cannot be resent this way.
This repeats an old notification; it does not retrieve the latest invoice status or automatically move the message to another channel. Changing a route does not rebuild the content of an old event.
5. Check the new record
Refresh the list and find the new delivery of the same event. Wait for the result; a queued notification is not yet a success. If it fails again, read the new reason and check the recipient instead of repeatedly clicking the same action.
The shop’s handler must store event_id and avoid fulfilling the order twice. Even after successful delivery, fulfilment still requires the current invoice state. “Delivered” confirms the notification’s sending result, not payment of the order, a person reading the message, or your application completing its actions.