Webhooks vs. Polling in HubSpot–Salesforce: Performance, Scheduling, and Retries

Every integration begins as a trickle and becomes a river. The patterns you choose for change detection and delivery—webhooks, polling, platform events, bulk jobs—determine whether the system stays quiet and efficient or burns through limits and creates backlogs at the worst times. This playbook compares push and pull patterns for the HubSpot–Salesforce integration and gives you a pragmatic operating model for scheduling, throughput, and retries so that sync remains fast, polite, and observable.

When to push and when to pull

Push first, pull when you must. HubSpot property change notifications and Salesforce Platform Events let you react to actual changes instead of sweeping tables. Use push for hot paths—lifecycle changes, ownership, campaign membership—where humans notice lag. Use polling for cold paths that lack events or where batching is more efficient (for example, nightly reconciliation of long‑tail properties). Mixing both is normal; the discipline is to be explicit about which path owns which domain.

A simple reference architecture

Imagine three lanes:

Hot lane (push): event triggers from HubSpot or Salesforce enqueue a small job keyed by an external ID. A worker fetches the minimal payload, applies idempotent transforms, and writes. End‑to‑end latency targets minutes.
Warm lane (hourly poll): a narrow window keyed to SystemModstamp collects recently changed records where push is unavailable. Rate limits and concurrency keep the platform comfortable during business hours.
Cold lane (nightly reconcile): a batch process scans invariants (e.g., consent parity, lifecycle parity) and backfills drift. It writes in small batches and records deltas for review.

Scheduling that respects humans and limits

Not all hours are equal. Keep hot lanes 24/7, but shape warm and cold lanes around your tenants’ working hours and the platforms’ comfort zones. During the business day, cap concurrency and favor reads over writes. After hours, increase batch sizes safely. Always pace using platform‑published limits, not guesses; add margin for other apps sharing the same limits.

Designing idempotent writes

Idempotence turns retries into a feature rather than a risk. Use a stable external key, compute a target state for each record, and write only when the state differs. Avoid read‑modify‑write races by recomputing from source of truth on each attempt. When the destination rejects a write due to validation, emit a precise error class and stop retrying until a human or an automated fixer adjusts the source.

Backpressure, queues, and fairness

Queues protect downstream systems. Size your queues to hold at least a few hours of hot‑lane traffic and implement backpressure: when error rates rise or destinations slow, reduce concurrency and prefer failing fast with small, informative errors over building huge invisible backlogs. Ensure fairness: do not starve any segment or region because a single outlier payload hogs retries.

Observability that shortens incidents

Track three things for each lane: throughput (records processed per minute), latency (time from change to apply), and error rate by class (validation, permission, mapping, transient). Publish a tiny dashboard with green/yellow/red bands and page humans only on sustained red. For spikes, include top error messages and recent configuration changes so responders have context within one minute.

Nightly reconciliation as a safety net

Even with excellent push, drift accumulates. A nightly reconcile across a small set of invariants catches issues before humans notice. Keep it polite: limit writes per minute, pause during business hours, and record a reason for every fix. Reconcile first; only then troubleshoot the hot path to prevent recurrence.

Rollout without surprises

Shift gradually: pilot push for one object and one region, keep the poller as a fallback, and then widen scope. Turn on detailed logs for the first week and then taper to summaries once the error rate stabilizes. Keep the poller ready for emergency use, but do not let it run continuously in parallel with push; overlapping writes cause flapping.

FAQ

Are webhooks always better than polling?

No. Webhooks are superior for timeliness and efficiency, but they are only as reliable as the event source and your handler. Polling is simpler and robust when changes are sparse or when you need a nightly sweep for data hygiene. Use both, with clear ownership.

How do we avoid double processing when both push and pull exist?

Deduplicate by key and time window. Store a short‑lived “recently processed” cache keyed by external ID and property set. Pollers should skip records touched by the hot lane within the last window.

What retry policy works best?

Exponential backoff with jitter for transient errors, immediate stop for validation and permission issues. Keep a dead‑letter list that humans triage daily with clear owners for each error class.

Should we use bulk APIs?

Yes for cold lanes and large backfills, where you can trade latency for throughput. For hot lanes, bias toward single‑record or small‑batch writes so errors are actionable.

How do we test scheduling safely?

Replay a day’s worth of anonymized change logs in a sandbox or staging environment. Tune concurrency until throughput clears the day’s volume comfortably with margin. Then run a production watchlist for two weeks.