Getting Started
Webhook timing, queues, and prioritization
How OutboundSync queues, prioritizes, and processes webhook payloads to sync email and social activity into HubSpot and Salesforce — timing, retries, and ordering.
When to use this guide: Use this guide when you are onboarding OutboundSync or validating initial setup.
OutboundSync processes webhook payloads to sync email and social activity into CRM systems such as HubSpot and Salesforce.
OutboundSync’s infrastructure is designed to do this as close to real-time as possible, however beyond our infrastructure, there are a few additional considerations:
- The upstream sales engagement platforms have their own processing time related to events and how quickly they can send us the data.
- The applications downstream of OutboundSync have API rate limits.
- In order to mitigate race conditions that can result in inaccurate data and duplicate creation, we stagger how we process the data.
This article explains how delays work, which events skip delays, and how Category-based filters being enabled can affect the order of operations. They will be broken down into specific situations that can arise.
Normal events that have a CRM-specific delay
Section titled “Normal events that have a CRM-specific delay”Beyond standard rate limits, HubSpot, Salesforce, and other CRMs often have their own internal delay before newly created records are accessible via API by OutboundSync (or any other application).
In other words, any application pushes updates too quickly after first creating a lead, contact, company, or any other record, the CRM may return errors such as “record not found” or “value already exists.”
To avoid this, OutboundSync uses a common (default) delay for most webhook payloads.
You can slightly reduce this delay and the number of API calls into your CRM by pre-importing all the leads, contacts, and/or accounts from your campaigns in your CRM before starting your campaign.
Priority events that skip the default delay
Section titled “Priority events that skip the default delay”Some payload types are time-sensitive and should be sent to the CRM as quickly as possible.
For the following events, OutboundSync skips the user-level default delay:
EMAIL_REPLYLEAD_CATEGORY_UPDATEDCONNECTION_REQUEST_ACCEPTEDINMAIL_REPLY_RECEIVEDMESSAGE_REPLY_RECEIVED
When one of these payloads arrives, it is executed immediately, bypassing the normal queue delay.
Exception: Instantly campaign completed without reply
Section titled “Exception: Instantly campaign completed without reply”One Instantly LEAD_CATEGORY_UPDATED label is an exception. When Instantly reports that a campaign finished for a lead who never replied (campaign_completed_for_lead_without_reply), OutboundSync still syncs the event to your CRM, but it uses the normal CRM-specific delay instead of the priority lane. That keeps high-urgency category updates—such as interested or meeting booked—ahead of these terminal no-reply completions.
Special logic for Category-based filters
Section titled “Special logic for Category-based filters”Category-based filters are an optional OutboundSync feature where data is held in the middle until an approved lead category or status is sent to OutboundSync. After that, all data for that lead in that campaign is released. Read how category-based filters work here .
When filters are enabled, once OutboundSync receives a matching lead category for a lead, all payloads for that lead skip the normal queue so they can be processed more quickly.
At this point, OutboundSync begins applying a tiered delay for that lead’s payloads to keep updates orderly and prevent simultaneous writes on the same CRM record.
How this tiered delay works
Section titled “How this tiered delay works”First, OutboundSync identifies all pending payloads associated with that lead. Then all those payloads are processed sequentially with a 60-second staggered gap between them.
For example, say a lead has three pending payloads and is now categorized.
- Sent immediately
- Sent 60 seconds later
- Sent 120 seconds later
This protects against conflicts the CRM can produce when multiple updates are logged at the same time, while still ensuring these categorized leads are synced as quickly as possible.
Special case: Email reply vs. lead category updated events
Section titled “Special case: Email reply vs. lead category updated events”When both an EMAIL_REPLY and a LEAD_CATEGORY_UPDATED event appear in the queue for the same lead, OutboundSync ensures they are processed in the correct order.
Execution Order
Section titled “Execution Order”EMAIL_REPLYis always processed firstLEAD_CATEGORY_UPDATEDis processed afterward
OutboundSync may apply a minimal delay to the LEAD_CATEGORY_UPDATED event when necessary to maintain this sequence. This ordering ensures that the reply is present in the CRM before the lead category update triggers any native CRM workflows or user actions.
Summary of current behavior
Section titled “Summary of current behavior”Here is a summary of each scenario and OutboundSync’s processing behavior. This is in addition to any delays due to upstream Sales Engagement Platforms or downstream CRM API rate limits.
| Scenario | Processing behavior |
|---|---|
| Normal events (email sent, email open, etc.) | Use default CRM-specific queue delay |
| Priority events (email reply, lead category, etc.) | Skip default delay; execute immediately |
Instantly campaign_completed_for_lead_without_reply (as LEAD_CATEGORY_UPDATED) |
Still syncs; uses the default CRM-specific queue delay (not the priority lane) |
| Category-based filters | Skips the normal queue; apply sequential 60-second delay between that lead’s payloads |
| Email reply versus lead category updated events | Email reply is processed first; lead category update gets a small delay to ensure proper sequencing |
When a CRM connection breaks
Section titled “When a CRM connection breaks”Some CRM errors mean every sync to that connection would fail: expired or revoked authorization, the CRM app uninstalled, or a CRM billing or storage limit. When one of these happens, OutboundSync pauses CRM sync for that source and connection instead of sending each queued payload to a CRM that will reject it. Payloads that arrive while sync is paused are still logged, with an Error status and the Error Response sync_circuit_open.
Reconnecting the CRM resumes processing for new payloads. Payloads from the outage aren’t replayed automatically. See How to reprocess errored webhook logs. Temporary CRM errors, such as rate limits or brief outages, don’t pause sync. They’re covered in the next section.
To get alerted when this happens, subscribe a webhook to sync.failed and sync.recovered.
Automatic retries for temporary CRM errors
Section titled “Automatic retries for temporary CRM errors”OutboundSync re-queues a failed CRM write on its own only in the cases below:
| CRM | Retried automatically | How many times |
|---|---|---|
| HubSpot | Rate limits (429), HubSpot server errors (5xx), and network errors | Up to 7 more attempts, 1–6 minutes apart |
| Salesforce | Record lock errors (UNABLE_TO_LOCK_ROW) |
Up to 5 more attempts, 5–15 seconds apart |
| Attio, Close, HighLevel, Pipedrive | Rate limits (429) | Up to 7 more attempts, a few seconds apart (following the CRM’s Retry-After, up to 60 seconds) |
Any other temporary error is logged once with an Error status and isn’t retried automatically. That includes Salesforce rate limits, server errors, and expired sessions (INVALID_SESSION_ID), and server or network errors on Attio, Close, HighLevel, and Pipedrive. A sync whose automatic retries run out also ends as Error. To push these to your CRM, see How to reprocess errored webhook logs.
When an automatic retry succeeds, HubSpot, Salesforce, and Close update the original log entry to Success. Attio, HighLevel, and Pipedrive record the successful retry as a new entry, and the original entry stays Error.
Temporary errors don’t count toward sync.failed alerts. The one exception is Salesforce record lock errors that still fail after their retries; those count as failures.
