Sizing an event data sync against Salesforce API limits

Week two of the sale, and the registration feed into the CRM stops at 14:40 with an error nobody on the events team has seen before. The Salesforce admin has seen it plenty of times. The org has spent its 24 hour API allowance, and it will not get any more until the rolling window moves.

What makes this annoying is that the failure lands on the marketing team rather than on the integration, because the visible symptom is that new registrants are not receiving the confirmation journey. What makes it avoidable is that Salesforce API limits are published, arithmetic, and knowable a month before anybody writes the sync.

What the 100,000 number actually covers

Salesforce (2026) publishes the allocation in a limits cheat sheet, and the shape matters more than the headline. Enterprise, Unlimited and Performance editions get "100,000 + (number of licenses x calls per license type) + purchased API Call Add-Ons" total API requests per 24 hours. Developer Edition gets 15,000 flat.

The licence multiplier is the part people forget in both directions. A Salesforce or Salesforce Platform licence is worth 1,000 calls on Enterprise and 5,000 on Unlimited, while a Lightning Platform One App licence, a Customer Community Plus licence and a Partner Community licence are each worth 200.

So the real allowance for a mid-sized organiser running Enterprise with 250 Salesforce licences is 100,000 plus 250,000, which is 350,000 requests per 24 hours. That is a comfortable number. The same organisation on Enterprise with 40 licences has 140,000, which is a much tighter one, and the difference is invisible from the events side unless somebody asks.

Ask. It is a five minute question to a Salesforce admin and it changes the design.

How much does a 40,000 record sync cost?

Take the naive version first, because it is what gets built when nobody has done this arithmetic.

Forty thousand registrations, one API call per record to create or update a contact. That is 40,000 requests, which is 40 per cent of the 100,000 base allowance and 11.4 per cent of the 350,000 the licensed org actually has. On the smaller org above it is 28.6 per cent. On Developer Edition, where somebody is probably prototyping, 40,000 requests is 267 per cent of the 15,000 available, so the prototype fails at record 15,000 and everybody learns something.

Now add the part that always appears in the second week. To decide whether to insert or update, the integration first queries Salesforce for an existing contact by email. That is a second call per record, so 80,000 requests, which is 80 per cent of the base and 22.9 per cent of the licensed allowance.

Then add the daily reality. The sync does not run once. It runs every hour during an open sale to keep the nurture journeys current, and even if only 900 records changed in the last hour, a badly written job re-sends the whole file. Twenty-four runs at 80,000 requests is 1,920,000 requests against an allowance of 350,000, and the feed is dead by 05:00.

Those three versions are the same business requirement costed three ways, and the only thing separating them is design.

Where the second call per record comes from

It comes from doing the matching on your side of the boundary, and there is a standard way to stop.

Salesforce supports upsert against an external identifier field, which lets one call carry the decision. Create an external id field on the contact object holding your registration platform's person identifier, mark it unique, and the upsert resolves insert or update server-side. Forty thousand records at one call each rather than two, and the matching logic lives in one place rather than being reimplemented in your integration.

The same field is what makes a retry safe, because an upsert on a unique external key applied twice produces the same result as applying it once. That property has a name and its own set of design decisions, covered in why an idempotency key matters when you push registrations into a CRM.

Sizing the same load as a bulk job

Bulk API 2.0 exists for exactly this shape of work and the numbers are not close.

Salesforce (2026) documents a maximum of "150,000,000" records uploaded per 24-hour rolling period and up to "15,000 batches per rolling 24-hour period", with Bulk API 2.0 accepting "150 MB per job" and handling the batching internally. Forty thousand registration rows at roughly 600 bytes each is about 24 MB, so the whole load fits in a single job with room to spare.

Count the calls. Create the job, upload the data, close the job, poll for status until it completes, then fetch the results. Ten status polls is generous for a job of this size. That is somewhere around 14 requests where the record-by-record version spent 40,000, and 40,000 records against a 150,000,000 daily bulk ceiling is 0.027 per cent of it.

There is a real trade. Bulk is asynchronous, so the confirmation email cannot fire off the back of the same call, and per-record error handling means reading a results file rather than catching an exception. For a nightly or hourly reconciliation load that is fine. For the twenty registrations a minute arriving during a launch spike where somebody needs a confirmation within seconds, it is the wrong tool, and the correct architecture usually runs both: a real-time path for the individual record and a bulk path for the reconciliation sweep.

What breaks before the daily limit does?

Concurrency, usually, and it catches teams who solved the daily allowance and thought they were finished.

Salesforce (2026) allows 25 concurrent requests running longer than 20 seconds in production organisations and sandboxes, and 5 in Developer and Trial organisations. Short requests are not counted. The ceiling exists for the slow ones.

Here is how an event team walks into it. Somebody parallelises the post-show extraction, firing one SOQL export per exhibitor across 60 exhibitors at once because it finishes faster. Each query scans a large object and takes 25 seconds. The first 25 run, the twenty-sixth is refused, and the error message is about concurrent requests rather than about anything the events team recognises.

The fix is a worker pool with a fixed size rather than a fan-out, and a hard rule that any query expected to exceed 20 seconds gets counted against a budget of 25. This is a different limit shape from the one Microsoft applies to Dataverse, where the ceiling is enforced per user over a five minute sliding window (Microsoft, 2026), and the show week version of that problem needs its own treatment.

Show week is when the allowance is thinnest

Every integration you own gets busy in the same seven days, and the allowance is shared across all of them.

Registration syncs run hotter because on-site registrations arrive in bursts. Badge scanning pushes leads. The mobile app refreshes. Finance runs reconciliation queries. Somebody in marketing sets a list export running because they want to send a same-day follow-up. None of these know about each other and all of them draw on the same 24 hour bucket.

Two habits help. First, instrument it: Salesforce exposes API usage per org, so read the remaining allowance at the start of every scheduled job and log it, which turns the eventual incident into a chart with a slope you can extrapolate. Second, give the integration user its own connected app so that its consumption is attributable, because a shared credential makes it impossible to say which job spent the allowance.

When you do hit a limit, the response matters as much as the prevention, and a backoff strategy that survives the busiest registration day is worth having written down before you need it.

Where this stops

Arithmetic on published limits gets you a design that will not fall over. It does not get you a working integration, and two things sit outside the numbers.

The first is that the allowance is org-wide and your team probably does not control the org. A well-sized events sync consuming 15 per cent of the daily allowance is a good citizen right up to the morning somebody in another department switches on a data enrichment tool that consumes 70 per cent. Your job fails, your dashboard is wrong, and the cause is in a system you cannot see. The only defence is the logging above, so that the conversation starts with evidence.

The second is that record counts are the wrong unit for some of this work. A single Apex trigger firing on contact insert can turn one API call into a chain of internal operations, and the limits that bite there are governor limits inside the platform rather than the API allowance outside it. A sync that is well within its request budget can still fail because the org's own automation cannot absorb 40,000 inserts in a burst. Ask the Salesforce admin what fires on contact insert before you schedule a large load, and expect the answer to change the schedule.

The first step this week is a single number. Ask your Salesforce administrator for the org's edition and licence count, work out the 24 hour allowance, then take your largest registration file and multiply its row count by the calls per record your current integration makes. If the result is above a quarter of the allowance, the design needs a bulk path before the next sale opens. The rest of what an integration owes the systems around it sits with this cluster.