HubSpot and Salesforce - How to Budget the Salesforce API Calls the Integration Consumes

The HubSpot–Salesforce connector has no API allowance of its own, so it spends the same Salesforce allocation as every other connected system, and once that allocation is exhausted Salesforce stops accepting calls from all of them until the window clears.

This covers the API allocation only — how it is calculated, what consumes it, and how to cap and monitor HubSpot's share — because field mapping, selective sync design and lead conversion each depend on the integration running at all, which is what the allocation governs.

Terms

API allocation — the number of API requests a Salesforce org will accept, counted across every connected application together. Not per app.

Rolling 24-hour window — the period the allocation is measured over. Salesforce counts the aggregate of calls made in the preceding 24 hours, so consumption expires continuously rather than resetting at a fixed time.

Inclusion list — a HubSpot list that restricts which records are eligible to sync. Records outside it are not sent, and therefore cost nothing.

Sync Health — the tab in HubSpot's Salesforce integration settings that reports API consumption and sync errors.

How the allocation is calculated

Salesforce derives the daily figure from a base allowance plus a per-licence amount, as set out in Salesforce's own guidance on API limits.

Enterprise Edition starts at 100,000 requests and adds 1,000 per Salesforce licence, so an org with 15 licences has 115,000, while Unlimited Edition applies the same 100,000 base with 5,000 per licence and purchased add-ons raise the total further.

Because the figure is derived from licence count rather than fixed, it changes whenever the org does — and two of its properties matter more than its size.

The figure is shared rather than divided, so every integration touching the org draws from the same number — HubSpot, the data warehouse loader, the marketing tool, a middleware platform and anything a developer wrote. Because Salesforce reports consumption as a single pool, HubSpot's share is only identifiable from HubSpot's own reporting, which is why an org can be exhausted without anyone knowing which system did it.

The window rolls rather than resetting, so a call made 25 hours ago no longer counts against the total. That explains why an exhausted org sometimes recovers at an hour nobody predicted, and why waiting for midnight is the wrong mental model: nothing resets at a fixed time, and capacity returns gradually as older calls age out.

What actually spends calls

Record volume is the obvious driver but not the only one, because consumption scales with how many records are eligible to sync, how frequently they change, and how many fields are mapped — a record that changes on any one mapped field becomes a call regardless of how trivial the change was.

A bulk import into HubSpot that touches syncing records will queue a call per record. So will a workflow that rewrites a mapped property across a large list, or a data cleanup that normalises a field on ten thousand companies. These are the events that exhaust an allocation, and they are usually run by someone who has no reason to connect the two facts.

The practical consequence is that the highest-risk moment for an integration is not steady-state operation but the afternoon somebody runs a well-intentioned bulk update, since nothing in the import interface indicates that the operation will also consume a shared Salesforce quota.

Procedure: set a budget before you need one

1. Find the org's total allocation. In Salesforce, open Setup and search for System Overview; the API Requests figure shows usage against the limit for the trailing 24 hours.
2. Establish HubSpot's current consumption. In HubSpot, click the settings icon, go to Integrations → Connected Apps → Salesforce, and open the Sync Health tab. The API call use section reports calls used in the last 24 hours, per HubSpot's documentation on managing integration API calls.
3. Subtract every other consumer. Total allocation minus HubSpot's usage is what remains for everything else — confirm that the remainder is genuinely sufficient rather than assuming it.
4. Set a cap. In the same API call use section, enter a figure under Allocated to HubSpot and save. This is documented in HubSpot's article on adjusting the Salesforce API call limit. Setting it below the org total means a HubSpot-side incident degrades HubSpot's sync instead of taking every other integration down with it.
5. Turn on sync error notifications. In the Sync errors section, click Manage notifications, switch notifications on, and choose Instantly, Daily or Weekly. They are off until you do this, which is why sync failures are so often discovered weeks later.
6. Reduce eligible volume if the numbers do not work. An inclusion list restricting sync to records that meet a qualification bar removes their calls entirely, and is more effective than trimming mapped fields.
7. Verify by returning to Sync Health the following day and confirming that calls used sits comfortably below the cap, and that the cap sits comfortably below the org total. If either margin is thin, the next bulk import will exhaust it.

Configuration reference

Allocated to HubSpot — the ceiling HubSpot will not exceed, which should be set deliberately because leaving it at the org maximum permits HubSpot to consume the entire shared pool.

Limited by Salesforce — read-only, reflecting the limit Salesforce reports. It changes when licences or add-ons change, so a figure calculated once is not permanent.

API calls used — consumption across the trailing 24 hours, shown against the remainder of the cap rather than the org total.

Sync error notifications — off by default. Instantly, Daily or Weekly. Daily is a reasonable choice for most teams; Instantly is only useful if someone is genuinely on call for it.

Failure modes

Symptom: the sync stops, no configuration changed, and it resumes on its own hours later. Cause: the org allocation was exhausted and calls aged out of the rolling window. Fix: check API calls used in Sync Health against the cap. Trace what ran that day — a bulk import or a workflow rewriting a mapped property on a large list is the usual cause.

Symptom: an unrelated integration starts failing and nothing about it changed. Cause: HubSpot consumed the shared allocation. The other system's failure is a symptom of HubSpot's volume. Fix: set Allocated to HubSpot below the org total so HubSpot cannot starve other consumers.

Symptom: sync errors accumulate for weeks before anyone notices. Cause: notifications are off by default. Fix: enable them in the Sync errors section and name someone accountable for the digest.

Symptom: the allocation drops without explanation. Cause: the total is derived from licence count. Removing Salesforce licences reduces it — 10 licences removed from an Enterprise org is 10,000 fewer daily calls. Fix: recalculate the budget whenever licence count changes, and treat a licence reduction as an integration event.

Symptom: a one-off data cleanup takes the sync down mid-afternoon. Cause: every touched record that is eligible to sync produced a call. Fix: run bulk operations against records excluded by the inclusion list where possible, or schedule them when the trailing window has most capacity, and watch Sync Health while they run.

What this does not cover

HubSpot does not publish the number of API calls a given sync operation costs, so consumption cannot be predicted from record counts in advance. It has to be measured against your own org.

The figures above are the standard Enterprise and Unlimited formulas. Editions, add-ons and negotiated agreements vary, and the number Salesforce reports for your org is authoritative over any formula.

This says nothing about which records should sync. An inclusion list is described here purely as a way to reduce consumption; designing one is a separate decision that belongs with your qualification model.

Verification checklist

• The org's total allocation is known and was read from Salesforce, not calculated
• Allocated to HubSpot is set below that total, with a stated margin for other consumers
• Sync error notifications are on and go to a named person
• API calls used has been observed across a full working day, not a quiet one
• Someone owns recalculating the budget when Salesforce licence count changes
• The team running bulk imports knows they consume the same allocation

Integration scoping and pricing is on our store.