Webhook timing, queues, and prioritization
Last updated December 23, 2025
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
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
Some payload types are time-sensitive and should 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.
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
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
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
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
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 |
| 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 |