Skip to main content

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

  1. Subscribe: Create a webhook subscription using the Redo API, specifying your endpoint URL and the events you want to receive
  2. Receive: When a subscribed event occurs, Redo sends an HTTP POST request to your endpoint with the event data
  3. Acknowledge: Your endpoint responds with a 2xx status code to confirm receipt
  4. 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 the Authorization header of every webhook delivery:
Always verify the Authorization header matches your expected secret before processing webhook payloads.

Creating a Webhook Subscription

Use the Create Webhook endpoint to subscribe to events:

Parameters

url
string
required
The HTTPS endpoint where Redo should send webhook events.
secret
string
required
A secret token you generate. Redo will include this in the Authorization header of webhook requests.
topics
array
required
Array of event topics to subscribe to. Available topics:
  • return.created - A new return was created
  • return.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

created
string
A new return has been created by a customer or team member.
updated
string
An existing return has been updated (status changed, items modified, etc.).
backfill
string
A historical event being sent during webhook setup or replay.

Event Payload

type
string
Event type: created, updated, or backfill
at
string
ISO 8601 timestamp of when the event occurred
merchantName
string
The name of the merchant team that owns this return. Useful for 3PL and integration consumers that process webhooks across multiple merchants.
return
object
Complete return object. See the Returns API reference for full schema.
return.items[].upc
string
Universal Product Code (barcode) for the returned item, snapshotted from the product at return-creation time. null if no barcode was recorded for the item.
order
object
Original order data associated with the return

Best Practices

Respond with a 2xx status code within 5 seconds of receiving the webhook. Process the event asynchronously if needed.
Store processed event IDs to prevent duplicate processing. Use the combination of return.id and at timestamp as a unique key.
Always validate that the Authorization header contains your expected secret.
Your webhook endpoint should gracefully handle all event types, including backfill events sent during setup.
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:
This is useful for:
  • 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

  • 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
Implement idempotency using event IDs to safely handle duplicate deliveries.
Events are ordered per return, but different returns may arrive in any order. Always process events based on the at timestamp.