The SF Dev
2 min readThe SF Dev Team

Designing Salesforce Integrations That Don't Blow Through API Limits

  • Salesforce
  • Integrations
  • APIs
  • Architecture

Every Salesforce org has a daily API request allocation, and every integration team eventually meets it — usually at the worst possible time, when a backfill job and a busy sales day collide. The fix is architectural, not reactive.

Know your real budget

Your daily limit is roughly base + (licenses × per-license entitlement), visible in Setup → Company Information. Now subtract everything else that consumes it: managed packages, BI connectors, marketing tools, and that one Zapier automation someone set up in 2024. The number left over is your integration budget — it's usually half of what teams assume.

The four patterns, ranked by API efficiency

1. Event-driven (best)

Platform Events and Change Data Capture push changes out of Salesforce without polling. A CDC subscription consumes event allocations, not REST API calls, and eliminates the single most wasteful pattern in existence: the every-five-minutes "did anything change?" poll.

2. Bulk API for volume

Moving more than a few thousand records? Bulk API 2.0 counts one call per batch, not per record. A 500,000-record sync that would consume 2,500 REST calls (at 200 records per call) takes a handful of Bulk API jobs.

3. Composite API for chatty operations

Creating an account, a contact, and an opportunity together is three REST calls — or one Composite call. Composite requests also give you all-or-nothing transaction semantics, which your data quality team will thank you for.

4. Plain REST (use sparingly)

Fine for low-volume, user-triggered operations. A problem the moment anyone puts it in a loop.

Design rules we apply on every engagement

  • Idempotency keys on every write. Retries are inevitable; duplicate opportunities shouldn't be. Use external ID upserts so a replayed message is a no-op.
  • Dead-letter queues, not silent drops. A failed sync record goes somewhere a human can see, with enough context to replay it.
  • Backpressure before the limit, not at it. Alert at 70% of daily allocation. Throttle at 85%. Never find out from a REQUEST_LIMIT_EXCEEDED error.
  • One integration user per system. Shared credentials make usage attribution impossible and incident response miserable.

A quick capacity sanity check

Before building, estimate: (records/day ÷ batch size) × sync frequency × number of systems. If that number exceeds 30% of your available budget, redesign now — event-driven sync or wider batches — because data volume only grows.

We design and build these integrations for a living, from two-system syncs to full middleware platforms. If your integration roadmap is bigger than your API budget, let's talk.

Working through this problem yourself?

We've probably built it before. A short call costs nothing and usually saves weeks.