Replaying Events

Replay lets you resend any historical webhook event to your current destinations. It's like having a time machine for your webhooks—perfect for testing, debugging, and recovering from failures.

What is replay?

Replay takes an event that webhook.rodeo received in the past and sends it again to your current webhook configuration. The original request data (headers, body, signature) is preserved exactly as it was.

Think of it like pressing "send again" on an email—same content, new delivery attempt.

When to use replay

Testing new endpoints

You just deployed a new version of your webhook handler:

# Before: webhooks went to v1.your-app.com
# After: webhooks go to v2.your-app.com

Replay recent webhooks to test your new endpoint without waiting for real events to arrive.

Debugging failures

Your endpoint was returning 500 errors yesterday, but you've fixed the bug:

1. Find the failed events in your dashboard
2. Replay them one by one
3. Verify they now succeed
4. Check the response to confirm correct processing

Data recovery

Your database went down for 30 minutes, missing several webhooks:

1. Filter events by the downtime window
2. Replay all events from that period
3. Your application reprocesses them
4. Data is recovered

Integration testing

Before pointing a production webhook at your endpoint:

1. Create a test webhook
2. Send sample events
3. Replay them multiple times to test edge cases
4. Verify your error handling and validation

How to replay

From event details

1. Navigate to any event in your dashboard
2. Click the "Replay Webhook" button
3. Confirm the replay
4. Watch the new delivery attempt appear

From events list

1. Find the event you want to replay
2. Click the replay icon (circular arrow)
3. The event is resent immediately

What you'll see

After triggering a replay:

• A new delivery attempt is created
• The attempt number increments (Attempt #5, #6, etc.)
• Response status and latency are recorded
• The event detail page updates with the new attempt

What happens during replay

Here's the replay flow step-by-step:

1. Fetch original event - Retrieve stored request data
2. Check current config - Use the webhook's current forward URL/Slack settings
3. Forward request - Send with all original headers and body
4. Add replay headers - Include X-Rodeo-Attempt: N
5. Capture response - Record status, headers, body, latency
6. Update event - New delivery attempt added to history

Important notes

• Replay uses your current webhook configuration
• If you've changed the forward URL, replay goes to the new URL
• Signature headers are preserved from the original request
• Client IP remains the original sender's IP
• Timestamp shows when the event was originally received

Best practices

Replay safely

• Test endpoints first - Don't replay to production without testing
• Check idempotency - Ensure your app can handle duplicate events
• Review the payload - Make sure the data is still relevant

Avoid replay abuse

• Don't spam replays - Replaying rapidly can overwhelm your endpoint
• Respect rate limits - Replays count toward your forwarding quota
• Use for recovery, not regular flow - Replay is a tool, not a feature to rely on

Idempotent webhooks

Design your webhook handlers to be idempotent (safe to replay):

// Good: Check if already processed
async function handleWebhook(event) {
  const requestId = event.headers['x-rodeo-request-id']
  
  // Check if we've seen this request ID before
  const existing = await db.findByRequestId(requestId)
  if (existing) {
    return { status: 'already_processed' }
  }
  
  // Process webhook...
  await processEvent(event.body)
  
  // Save request ID to prevent duplicate processing
  await db.saveRequestId(requestId)
  
  return { status: 'processed' }
}

This pattern makes replays safe—your app will recognize it's a duplicate and skip reprocessing.