Webhook deliveries

Check what happened between event creation and your receiver response. Use the delivery list to track progress and the details of each attempt to investigate failures.

To register a destination or change the events it receives, use Webhooks.

Event, delivery and attempt

An event describes a change, such as charge.paid. A delivery sends that event to a webhook. An attempt is each HTTP call made to complete the delivery.

A delivery may have several attempts, all with the same webhook-id. Use the identifier returned by the attempt query to retrieve its details; it is different from event and delivery IDs.

Use the event to avoid repeating its effect in your system and the delivery to recognize retries. See Handle redeliveries and ordering.

Track a delivery

List deliveries and use the id of a result to retrieve it. Progress information may appear with a delay; the absence of a record does not prove that the event was never sent.

The list shows the most recent deliveries first. You can filter by webhook, event type, status and delivery creation period. If you already have the event UUID, use event_id to group its deliveries, including manual resends. To find the event by resource first, see Webhook events. The created_gte and created_lte limits are inclusive. The query covers up to 30 days from delivery creation, even if you omit the period.

Start listing without a cursor, process list and copy page.next_after to after while page.has_next is true. Keep the filters while navigating. To go back, use page.previous_before in before. Copy the entire cursor and do not send both directions in the same request. See Listing and pagination.

Tracking dates are returned in UTC Unix seconds. event_created_at identifies the original event creation time; created_at identifies the delivery creation time. These dates may differ in a resend. deadline_at is the deadline for completing the delivery, and next_attempt_at gives the next scheduled attempt when available. Queries do not start or speed up deliveries.

A paused queue prevents new attempts but keeps the original delivery deadline. Check is_paused in the webhook configuration before investigating a delay. See Pause and resume the queue.

An HTTP 2xx response confirms that the receiver accepted the delivery. It does not prove subsequent processing in the destination system. Check your application records as well.

Query attempts and responses

To query the HTTP response and body of a webhook attempt through the API, list attempts for the delivery and retrieve one to see the available details. The record includes the HTTP response, duration, error and destination used when those data were captured.

The list contains HTTP calls to the receiver. A wait before sending is not an HTTP attempt and may leave the delivery pending with an empty attempt list. Attempts appear from newest to oldest. Use pagination to browse the complete available history.

In attempts, created_at indicates when the attempt finished. duration_ms measures the total attempt time, which may include preparation and waiting before the HTTP call. Do not use this value alone as your receiver response time.

status_code: null means that no HTTP status is available. In this case, the error may help identify a connection failure or timeout. A failed attempt does not mean that the delivery has ended: check its progress and the next scheduled attempt.

destination_ip identifies the destination used for that connection. If a proxy sits in front of the receiver, this IP may belong to the proxy. The field does not identify the Raims source IP or the current result of a DNS query.

Request and response bodies are in the attempt details. request_available and response_body_available indicate their availability. An unavailable body differs from an empty body that was recorded. response_body_truncated: true means that the capture is partial; the content may not be complete JSON. Response capture is limited to 8 KiB. Binary, compressed or invalid UTF-8 responses may also be unavailable.

Older records may not include a body, URL or IP. The presence of metadata does not guarantee that those data were captured. Do not include secrets or unnecessary personal data in receiver responses.

30-day history

The API keeps the delivery, its attempts and captured bodies available for query for 30 days from delivery creation, shown in created_at. After that period, they no longer appear in queries. A new attempt for the same delivery does not restart the 30 days.

A resend creates another delivery with its own query period. The limit for requesting that resend remains 15 days from original event creation, shown in event_created_at. Keeping the history for 30 days does not extend that limit.

In the Dashboard, logs for each attempt can be queried for 30 days from that attempt's completion. A record may therefore still appear in logs after the API delivery period has ended.

Investigate a failure

Query the delivery and open the most recent attempt. The attempt HTTP status was returned by the receiver or a layer in front of it; it differs from the status of the request used to query the Raims API.

If a broad delivery query returns 503, wait and try a shorter period or more specific filters. Also check the general guidance for API unavailability.

Check the URL, certificate, signature and firewall rules before requesting another delivery. Automatic Production and Sandbox deadlines are explained in Webhook failures and retries.

Advance an attempt

If the receiver has been fixed and the delivery is still waiting for an attempt, use Advance an attempt. The delivery must be pending, within its deadline, with an active webhook and an unpaused queue.

The action requests that the next attempt become eligible to run before its scheduled time, subject to sending limits. It preserves the event and delivery; the delivery_id stays the same. It does not create another delivery, extend the deadline or increase the number of attempts allowed in Sandbox.

A 202 response confirms receipt of the request. The delivery condition is checked again before advancing the attempt, because it may change in that interval. Query the same delivery to track the result. An attempt in progress or a delivery that has already ended cannot be advanced. For a delivery that has ended, check resend eligibility.

The technical event webhook.test cannot be advanced. If you need to test the receiver again, use Send a test event.

Resend an event

Request a resend from an event delivery. The event must have been created no more than 15 days ago, its body must remain available and its type must still be selected in an active webhook.

If you have the event ID and need to choose the destination, use Send an event to a webhook. This route allows the first delivery to that webhook and follows the same eligibility limits.

The request returns event_id and delivery_id. Query the new delivery to track the result. Acceptance of the request does not confirm receipt or cancel automatic attempts for the previous delivery. The record may take a few moments to appear in the query after acceptance; wait briefly before querying again.

If the queue is paused, the new delivery also waits for it to resume while its own attempt deadline continues to run.

A resend preserves the original body bytes, including its id and created_at, and uses the current webhook URL and secret. Prepare the receiver to receive the same event in different deliveries without repeating its effect. Resending does not repeat the financial transaction that created the event.

The new delivery has its own attempt deadline. The limit for requesting another resend remains tied to original event creation; resending does not renew the 15 days. See Manual event resends.

webhook.test events cannot be resent. To check the receiver again, request another test.

Deleting a webhook preserves the history available for query. Use its identifier as a filter to find previous deliveries. Deletion prevents resending to that webhook.

Resend multiple events

Use Resend multiple events to request deliveries for up to 500 IDs in one request. Each item follows the same conditions as an individual resend. You can combine deliveries for different webhooks from the same company and environment.

The response keeps the order of the submitted IDs. For each accepted item, it returns the original event and new delivery. A rejected item includes the reason in error, without preventing acceptance of the others. HTTP 202 confirms processing of the request; check each result before tracking the new deliveries.

If the same ID appears more than once, or several deliveries refer to the same event and webhook, the request creates a single new delivery for that pair. The corresponding results return the same delivery_id.

Resending does not cancel previous attempts, including those in progress. Fix the receiver before submitting the request and keep deduplication by event ID. If a failure prevents the API response, some items may have been accepted. Query deliveries before repeating the entire request.

Company and environment

Use an API key from the same company and environment as the webhooks. Filters and identifiers do not grant access to another company or environment. The console accepts Sandbox keys only.

Queries do not change the delivery or financial resource. Keep keys and secrets in the private integration environment.