Retries & Error Handling

Pipes.bot uses automatic retries with exponential backoff to ensure reliable delivery. If all retries fail, messages are queued and the system falls back to WebSocket delivery.

Retry schedule

When your endpoint returns a non-2xx status code or is unreachable, Pipes.bot retries up to 3 times:

Attempt	Delay	Total elapsed
1	Immediate	0s
2	2 seconds	2s
3	8 seconds	10s

What counts as a failure

HTTP status codes outside 200-299
Connection timeouts (10 second limit)
DNS resolution failures
Network errors (connection refused, reset, etc.)

After all retries fail

If all 3 attempts fail:

The payload is queued in the WebhookDelivery table with full details (payload, error, attempt count)
The message is delivered via WebSocket as a fallback so you don't lose it
Failed deliveries are visible in your dashboard for debugging

Requirements for your endpoint

To ensure reliable delivery:

Respond quickly. Pipes.bot enforces a 10-second timeout per request. Do heavy processing asynchronously after responding.
Return 2xx on success. Any status outside 200-299 triggers a retry.
Be idempotent. Retries may deliver the same message more than once. Use the messages[].id field to deduplicate.
Use HTTPS. While HTTP is accepted, HTTPS is strongly recommended for production.
Keep your endpoint available. Prolonged downtime will exhaust retries and fall back to WebSocket delivery.

URL restrictions

Webhook URLs must point to a public server. The following are blocked for security (SSRF protection):

localhost, 127.0.0.0/8, ::1
Private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Link-local: 169.254.0.0/16, fe80::/10
CGNAT: 100.64.0.0/10
Non-HTTP schemes (ftp://, file://, etc.)