Skip to main content

Callback Logs

Shufti's Callback Logs feature provides Merchants with a complete delivery history of every callback sent from Shufti to their configured callback URL. Each entry records the event that triggered the callback, the server response, the exact payload that was sent, and the delivery status. Merchants can use the logs to monitor delivery health, investigate failed callbacks, and resend deliveries directly from the Backoffice or through the API.

Callback Logs are available under Backoffice Settings > API Configurations > Callback Logs.

How It Works​

Whenever a callback event is triggered for a verification request, Shufti attempts to deliver it to the configured URL. The outcome of every delivery attempt, whether successful or failed, is recorded as a Callback Log entry. Each entry includes:

  • Reference ID and Customer ID of the associated verification
  • Event that triggered the callback (e.g. verification.accepted, request.pending, verification.declined)
  • HTTP Code returned by the Merchant's server
  • Status of the delivery (Delivered, Failed, Permanent Failed)
  • First Attempt and Last Attempt timestamps
  • Next Retry time, if the callback is scheduled for a retry

Delivery Statuses​

StatusDescription
DeliveredThe callback was successfully received by the Merchant's server (2xx response).
FailedThe delivery attempt failed. Shufti will automatically retry.
Permanent FailedAll automatic retry attempts have been exhausted. The callback will not be retried automatically.

Investigating a Callback​

Selecting any log entry opens the Callback Details popup, which displays:

  • The Callback URL that the callback was sent to
  • The Server Response returned by the Merchant's endpoint
  • The full Payload Sent, which mirrors the verification response payload structure

The Server Response section shows the exact error returned by the Merchant's server, and the Payload Sent section shows the data Shufti dispatched.

Resending a Callback​

Merchants can manually resend any callback, including those that were delivered successfully, in case the event needs to be re-processed on the Merchant's side.

Resending from the Backoffice​

  1. Navigate to API Configurations > Callback Logs.
  2. Open the callback entry you wish to resend.
  3. Click Resend Callback in the Callback Details popup.
  4. On a successful delivery, a confirmation is shown.

Resending via API​

Callbacks can also be resent programmatically using the resend endpoint. This is useful for automating recovery flows or re-processing events on the Merchant's side.

Endpoint

endpoint
//POST /callback/resend HTTP/1.1
//Host: api.shuftipro.com
//Content-Type: application/json
//Authorization: Basic NmI4NmIyNzNmZjM0ZmNlMTlkNmI4WJRTUxINTJHUw==
// replace "Basic" with "Bearer in case of Access Token"

Request Body

request-body
{
  "reference": "5e1cf8bc0a975a6e",
  "event": "verification.accepted"
}

Parameters

ParameterTypeRequiredDescription
referencestringYesThe reference ID of the verification whose callback should be resent.
eventstringYesThe specific callback event to resend (e.g. verification.accepted).

Successful Response

successful-response
{
  "reference": "5e1cf8bc0a975a6e",
  "event": "verification.accepted",
  "status": "scheduled",
  "scheduled_at": "2026-03-08T14:47:09+05:00"
}

Cooldown Period​

To prevent duplicate deliveries and protect Merchant systems from unintended traffic spikes, each callback can only be resent once per hour. This applies to both manual resends from the Backoffice and programmatic resends through the API.

Behavior During Cooldown​

  • If a callback has not been resent in the last hour, the resend is processed immediately.
  • If a callback was resent within the last hour, the next resend is scheduled for the time at which the one-hour cooldown ends. The callback will be delivered automatically at that time.
  • In the Backoffice, an active cooldown is indicated by a disabled Resend Callback button. Hovering over the button displays the scheduled delivery time.
  • In the API, an attempt to resend during an active cooldown will return a status: scheduled response along with the scheduled_at timestamp instead of a status: sent response. The request is not rejected.

Example: Cooldown Response​

cooldown-response
{
  "reference": "5e1cf8bc0a975a6e",
  "event": "verification.accepted",
  "status": "scheduled",
  "scheduled_at": "2026-03-08T14:47:09+05:00",
  "message": "A resend is already scheduled for this callback. It will be delivered at the scheduled time."
}