Overview
Webhooks allow your application to receive real-time notifications when events occur in Redo, such as when a return is created or updated. Instead of polling the API, webhooks push event data to your specified endpoint.How Webhooks Work
- Subscribe: Create a webhook subscription using the Redo API, specifying your endpoint URL and the events you want to receive
- Receive: When a subscribed event occurs, Redo sends an HTTP POST request to your endpoint with the event data
- Acknowledge: Your endpoint responds with a 2xx status code to confirm receipt
- Retry: If your endpoint doesn’t respond with a 2xx, Redo will retry the delivery multiple times before discarding the event
Webhook events are delivered in order for each individual subject (e.g., return). This ensures you process events in the correct sequence.
Authentication
Webhooks use Bearer token authentication with a secret you provide when creating the webhook subscription. Redo includes this secret in theAuthorization header of every webhook delivery:
Creating a Webhook Subscription
Use the Create Webhook endpoint to subscribe to events:Parameters
The HTTPS endpoint where Redo should send webhook events.
A secret token you generate. Redo will include this in the
Authorization header of webhook requests.Array of event topics to subscribe to. Available topics:
return.created- A new return was createdreturn.updated- An existing return was updated
Webhook Events
Return Events
Return events notify you when returns are created or updated in your store.Event Types
A new return has been created by a customer or team member.
An existing return has been updated (status changed, items modified, etc.).
A historical event being sent during webhook setup or replay.
Event Payload
Event type:
created, updated, or backfillISO 8601 timestamp of when the event occurred
Complete return object. See the Returns API reference for full schema.
Original order data associated with the return
Best Practices
Return 2xx status codes quickly
Return 2xx status codes quickly
Respond with a 2xx status code within 5 seconds of receiving the webhook. Process the event asynchronously if needed.
Implement idempotency
Implement idempotency
Store processed event IDs to prevent duplicate processing. Use the combination of
return.id and at timestamp as a unique key.Verify the authorization header
Verify the authorization header
Handle all event types
Handle all event types
Your webhook endpoint should gracefully handle all event types, including
backfill events sent during setup.Use HTTPS endpoints
Use HTTPS endpoints
Webhook URLs must use HTTPS to ensure secure transmission of data.
Testing Webhooks
Replay Events
You can replay webhook events using the Webhook Replay endpoint:- Testing your webhook endpoint
- Recovering from downtime
- Backfilling historical data
Local Development
For local development, use a tool like ngrok to expose your local server:Managing Webhooks
List Webhooks
Update a Webhook
Delete a Webhook
Troubleshooting
Webhook deliveries are failing
Webhook deliveries are failing
- Verify your endpoint returns a 2xx status code
- Check that your endpoint URL uses HTTPS
- Ensure your server is reachable from the internet
- Verify the Authorization header is being validated correctly
Receiving duplicate events
Receiving duplicate events
Implement idempotency using event IDs to safely handle duplicate deliveries.
Events are out of order
Events are out of order
Events are ordered per return, but different returns may arrive in any order. Always process events based on the
at timestamp.