Overview

Webhook subscriptions in Repliers require endpoint response times to be relatively quick. When your endpoint consistently exceeds high thresholds, your webhook subscription may be disabled to protect system reliability for all users.

Why Response Time Matters

System Resource Protection

Webhooks are designed to deliver real-time notifications, not to wait for long-running processes. When endpoints take too long to respond, it ties up server resources that need to handle thousands of webhook deliveries across our platform.

Industry Standard Practice

Most webhook providers enforce similar timeout policies (typically 3-10 seconds). This isn't unique to Repliers—it's a widely accepted standard that ensures webhook systems remain fast and reliable. Services like Stripe, GitHub, and Twilio all implement comparable timeout policies.

No Retry System

Repliers does not currently implement automatic retry logic for failed or slow webhook deliveries. This design choice prioritizes system simplicity and predictability. When an endpoint times out, the webhook delivery is considered failed, and repeated failures may result in subscription disabling.

Retrieving data on receiving endpoint failure**

If your endpoints fail to respond and capture our callback payloads, the data is not lost and we provide a mechanism for recovery. Please refer to this article showcasing how to replicate data.

https://help.repliers.com/en/article/data-replication-with-repliers-1nqvact/

Best Practices for Webhook Endpoints

Your webhook endpoint should respond quickly—ideally within 200-500ms. Here's how to achieve this:

Immediate Acknowledgment Pattern

Respond with a 200 OK status immediately upon receiving the webhook, then process the payload asynchronously. Your endpoint should simply capture and acknowledge—not process.

1. Receive webhook POST request
2. Store payload in database/queue
3. Return 200 OK immediately
4. Process payload separately via background worker

Use Message Queues

Implement a queue system (Redis, RabbitMQ, AWS SQS, etc.) to handle webhook payloads asynchronously. This ensures your endpoint responds instantly while processing happens in the background.

Avoid Synchronous Operations

Never perform these operations within your webhook endpoint handler:

• Database-intensive queries or complex calculations
• External API calls to third-party services
• File uploads or processing
• Email sending or notification dispatch

Optimize Your Infrastructure

• Use lightweight endpoint handlers dedicated solely to webhook receipt
• Ensure adequate server resources to handle incoming requests
• Monitor your endpoint's response times regularly
• Set up proper error logging to catch issues early

Questions This Article Answers

• Why do Repliers webhook endpoints need to respond quickly?
• What happens if my webhook endpoint is too slow or consistently exceeds response time thresholds?
• Why does Repliers disable webhook subscriptions for slow or failing endpoints?
• Is enforcing strict webhook timeouts a common industry practice or something unique to Repliers?
• What response time is recommended for my Repliers webhook endpoint (in milliseconds)?
• Does Repliers retry webhook deliveries if my endpoint times out or fails?
• If my webhook endpoint fails and misses the callback payloads, is the data lost?
• How can I recover or replicate data if my webhook endpoint fails to capture payloads?
• What is the recommended pattern for handling Repliers webhooks (immediate acknowledgment vs. processing in the request)?
• How should I structure my webhook endpoint to respond quickly but still process the data?
• Why should I use a message queue (Redis, RabbitMQ, AWS SQS, etc.) with Repliers webhooks?
• What kinds of operations should I avoid doing synchronously inside my webhook handler?
• How can I optimize my infrastructure to handle Repliers webhooks reliably?
• How should I monitor and log my webhook endpoint to catch performance issues early?

Updated on: 04/12/2025