Webhook forwarding with Additional Endpoints

When to use this guide: Use this guide when you are onboarding OutboundSync or validating initial setup.

OutboundSync allows you to forward webhook payloads to Additional Endpoints for flexible integrations. This guide explains how the forwarding process works, how rate limits and payload size issues are handled, and what retry mechanisms are in place.

OutboundSync always syncs the data to your CRM. Optional additional endpoints each forward either IMMEDIATELY when the payload arrives, or DELAYED until after the CRM sync finishes. Each endpoint can also be filtered to specific event types.

How It Works

When OutboundSync receives a webhook payload from the connected platform, we:

1. Deliver the webhook payload to the primary endpoint (the connected CRM)
2. Forward the same payload to any configured Additional Endpoints
3. Applies safeguards, including retry logic, random delays, and payload optimization, to ensure successful delivery even when downstream systems enforce strict rate limits or reject oversized requests.

Handling Rate Limits

Some destinations enforce API rate limits that restrict how many requests can be processed within a given time window. When requests exceed this limit, the endpoint returns a 429 Too Many Requests response.

OutboundSync’s Handling:

When OutboundSync receives a 429 Too Many Requests response:

1. A random delay between 0 and 300 seconds is added before the first retry for each payload.

   • This delay helps distribute retry attempts across time, preventing “retry storms” when many payloads fail simultaneously.
   • For example, if 100 payloads are being sent and 10 succeed while 90 return a 429, each of those 90 payloads will get a unique random delay between 0 and 300 seconds (e.g., 20s, 45s, etc.).
   • This ensures that retries are staggered rather than retried all at once, greatly reducing the chance of hitting the same rate limits again.

2. After the random delay, OutboundSync applies exponential backoff retries up to seven times:

Retry #	Additional delay (minutes)	Total delay formula
1	1	random(0–300s) + 2^(1-1) * 60s
2	2	random(0–300s) + 2^(2-1) * 60s
3	4	random(0–300s) + 2^(3-1) * 60s
4	8	random(0–300s) + 2^(4-1) * 60s
5	16	random(0–300s) + 2^(5-1) * 60s
6	30	random(0–300s) + 2^(6-1) * 60s
7	60	random(0–300s) + 2^(7-1) * 60s

Formula: TotalDelayForEachRetry = random(0–300s) + 2^(RetryNumber - 1) * 60s

This approach minimizes simultaneous retries and increases the likelihood of eventual success without overwhelming the endpoint.

Handling Payload Size Issues

Some destinations reject payloads that exceed a maximum size (e.g., 100 KB). In these cases, payloads may fail with a Payload Too Large error.

OutboundSync’s Handling:

• On detecting a size-related failure, we automatically optimize and retry the payload by converting all HTML fields into plain text.
• The optimized payload is retried under the same exponential backoff schedule.

Summary

OutboundSync ensures reliable delivery of webhook payloads to Additional Endpoints by:

• Detecting rate limit responses and retrying with exponential backoff (up to 7 times).
• Handling payload size errors by optimizing payloads (HTML → plain text).

This makes forwarding via Additional Endpoints robust even when partner systems enforce strict API limits or size constraints.

Next step

• Decide whether category-based filters should gate sync

Related guides

• Sending Test Webhook Payloads
• How Outboundsync Queues And Prioritizes Webhook Payloads