Callback Response

Overview

Callback Response is the HTTP or protocol result returned by a callback receiver to acknowledge, reject, or describe handling of a delivery attempt. It is used to tell the sender whether delivery was accepted and whether retry behavior should continue. It differs from the internal processing result, which may complete after an immediate acknowledgment.

A typical implementation works as follows: The handler validates enough information to decide its response, returns the documented status and body within the deadline, and processes durable work according to its design. Replay of Callback Response should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.

Common risks include returning success before durable receipt can lose events and while slow or inconsistent responses can cause repeated deliveries and overload. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Callback Response.

Core controls require teams to document exact success criteria, persist before acknowledging where required, respond quickly, avoid sensitive details, and make repeated delivery safe. A Callback Response handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.

Operational evidence should include event ID, response status and body, latency, durable receipt ID, retry decision, and later processing outcome. Callback Response should be documented alongside Webhook Timeout, Callback Handler, and Callback Retry.

Business actions triggered by Callback Response should be idempotent and should verify the current object state before fulfillment or accounting updates. Monitoring for Callback Response should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events.