Backoffice Callback Logs: View and Resend Callbacks
Callback Logs is the screen in the Backoffice where you check whether Shufti reached your callback URL, read exactly what your server replied, and resend a delivery that did not land. It covers every callback Shufti has attempted for your account, whether it succeeded or not, so you can answer "did this verification reach us?" without adding logging on your own side.
Callback Logs are available under Backoffice Settings > API Configurations > Callback Logs.
Opening Callback Logs
Go to Settings > API Configurations > Callback Logs. The screen lists every delivery attempt Shufti has made, with the most recent first. One row is one callback.
Reading the List
Each row summarises a single delivery attempt:
| Column | What it tells you |
|---|---|
| Reference ID / Customer ID | Which verification the callback belongs to, so you can trace it back to a request |
| Event | What triggered the delivery, such as verification.accepted or request.pending |
| HTTP Code | The code your server returned when Shufti called it |
| Status | Whether the delivery landed — see below |
| First Attempt / Last Attempt | When Shufti first tried, and when it last tried |
| Next Retry | When the next automatic attempt is due, if one is scheduled |
The Status column is the quickest way to spot a problem:
- Delivered — your endpoint answered with a 2xx, so nothing needs doing.
- Failed — the attempt did not get through. Shufti is still retrying automatically, so this can clear on its own.
- Permanent Failed — the automatic retries are used up. Nothing further will be sent unless you resend it yourself.
A run of Permanent Failed rows usually points at your endpoint rather than at any single verification — an expired certificate, a firewall rule, or a deploy that changed the route.
Inspecting a Single Delivery
Select any row to open the Callback Details popup. It shows three things:
- Callback URL — the address Shufti actually called, which is worth checking first if deliveries stopped after a configuration change.
- Server Response — the exact reply your endpoint returned, including the error text when it rejected the call.
- Payload Sent — the full body Shufti dispatched.
Between them these answer the two questions worth asking about a failed callback: what did we send, and what did your server say back. For what the individual payload fields mean, see Callback Logs: Webhook Delivery History.
Resending a Callback
Any callback can be resent from the Backoffice, including ones that were delivered successfully — useful when an event needs to be processed again on your side.
- Go to API Configurations > Callback Logs.
- Open the entry you want to resend.
- Click Resend Callback in the Callback Details popup.
- A confirmation appears once the delivery succeeds.
When the Resend Button Is Disabled
Each callback can only be resent once per hour, so repeated clicks cannot flood your endpoint.
If a callback was already resent within the last hour, the Resend Callback button appears disabled. Hover over it to see the time the delivery is scheduled for — the callback is sent automatically then, so there is nothing further to do. If the callback has not been resent in the last hour, the resend goes out straight away.
Resending Without the Backoffice
Callbacks can also be resent programmatically, which is the better route for automated recovery flows or for replaying a batch of events. The endpoint, its parameters and the cooldown responses are documented in Callback Logs: Webhook Delivery History.