Skip to main content

Recover a missing backend update

Section: DOC-IN-webhooks-deliveries#monitor-and-retry-deliveries.

An assistant has finished an order summary, but your application still shows it as processing. Trace the original run through webhook delivery and your own worker before starting more work. This recipe recovers a retained failed delivery after repairing the receiver.

You need the run or event identity from the affected work, your endpoint ID, a backend API key, and access to your receiver's logs and saved events. Use an isolated test order when practicing the flow.

1. Find where the update stopped​

Section: DOC-IN-webhooks-deliveries#deliveries.

Start with the delivery records for your endpoint and the time of the missing update. This example selects failed deliveries; remove or change status when you need to inspect other outcomes:

curl -X POST https://api.travila.ai/api/v1/webhooks/list-deliveries \
  -H "X-API-Key: sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
  "endpointId": "ep_abc123",
  "status": "DELIVERY_STATUS_FAILED",
  "createdAfter": "2026-08-01T00:00:00Z",
  "perPage": 50
}'

Reference: List webhook event deliveries · Request fields.

Use eventId when you know the exact event, and paginate the results. The list-deliveries reference describes the available filters. Retained records do not form a complete audit of every HTTP attempt.

What you findNext step
SCHEDULED or PROCESSINGCheck again for the same delivery; it has not reached a confirmed terminal result.
RETRYInspect the receiver failure and repair it while automatic retry is pending.
FAILEDRepair the receiver, then assess a manual retry of this retained delivery.
COMPLETEDYour receiver accepted it. Inspect the queued work and order update in your application.
DISCARDEDInspect retained history before concluding whether an earlier attempt occurred.
No matching deliveryCheck the original run, event selection and subscription timing. Absence from retained history does not establish that the run never completed.

The API prefixes the displayed states with DELIVERY_STATUS_. A COMPLETED delivery confirms HTTP acceptance, not successful execution of your background worker.

2. Repair the receiver​

Section: DOC-IN-webhooks-deliveries#receiving-webhooks.

Use the failure to choose the repair. Restore reachability for connection errors, correct signature verification for rejected authentic deliveries, or restore durable event storage when your receiver could not accept work.

Before replaying customer work, verify that your handler recognizes an already accepted event and that your worker checks the existing order update before repeating an external action. If the receiver accepted the event but its worker stopped, recover that saved work in your application; sending another webhook is not the first recovery step.

For out-of-order arrivals, use a documented resource version or sequence when available, or read current resource state. Arrival time alone cannot tell you which update wins.

Check whether the endpoint is still active​

Section: DOC-IN-webhooks-deliveries#auto-disable-on-sustained-failure.

Inspect the saved endpoint. If it is inactive, repair the receiver before re-enabling it with update-endpoint. Automatic disabling is deployment-dependent; a failed delivery does not prove that disabling happened.

Re-enabling permits later delivery. It does not prove that failed or discarded work replayed, so continue with the original retained records.

Understand the retry window​

Section: DOC-IN-webhooks-deliveries#retry-configuration.

Inspect the subscription's retryConfig through list-subscriptions. It records the requested strategy, count and base interval. Confirm the deployment's effective timing, counting and retention policy with your operator when planning how long an outage can be recovered.

Do not assume that every old event remains eligible for replay or that the configured interval promises an exact attempt time.

3. Replay the original eligible delivery​

Section: DOC-IN-webhooks-deliveries#retrying.

After repair, request a retry using its original delivery ID:

curl -X POST https://api.travila.ai/api/v1/webhooks/retry-delivery \
  -H "X-API-Key: sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
  "deliveryId": "del_xyz789"
}'

Reference: Retry a failed webhook delivery · Request fields.

Inspect the returned outcome and then read the delivery again. Do not create a new assistant run to compensate for a delivery problem: that can duplicate the work the first run already performed.

Finally, check the application record. Recovery is complete when the intended order update is present and the original event has been handled without repeating its business action. If replay eligibility or retention prevents recovery, reconcile the original run and saved application work instead of treating a new run as a retry.

Document ID: DOC-IN-webhooks-deliveries. Section identities and revisions.