💃 Dancing with API Limits 🕺

Good morning, Salesforce Nerds! Every Salesforce professional eventually has that late-night moment:

A production integration that happily hums along. Then out of nowhwere … 💥 

REQUEST_LIMIT_EXCEEDED

Suddenly your “real-time” sync is about as responsive as a dial-up modem from 1998.

API limits aren’t just arbitrary walls; they’re Salesforce’s way of making sure your org and every other tenant in the multi-tenant cloud stays healthy. ❤️ 

The trick isn’t to fear the limits but to design with them in mind.

Queuing, batching, and backoff are the holy trinity for handling high-volume integrations without drama. 🔗 

They sound like textbook patterns (and they are), but Salesforce gives us plenty of native tooling to implement them elegantly.

Let’s break it down. 👇️ 

TABLE OF CONTENTS

💃 Dancing with API Limits 🕺

• Queue It Up

• Batch Like a Pro

• Backoff, Buddy

• Two Sides of Limits

• Scaling Without Tears

PATIENCE IS A VIRTUE

QUEUE IT UP

Queuing is the architectural equivalent of a waiting room: requests line up until the system can process them safely. ▶️ ▶️ ▶️ 

Instead of ramming all your operations at Salesforce in one go, you spread them out over time.

In Salesforce, queuing takes a few different flavors:

📥️ Queueable Apex – Lets you enqueue lightweight jobs, chaining them if needed. Great for orchestrating callouts or breaking work into chunks.

✨ Platform Events – Think publish/subscribe messaging. They act as an async buffer between Salesforce and external systems.

💥 Change Data Capture (CDC) – More event-driven than pure queuing, but CDC still queues up record changes for external systems to process at their own pace.

Here’s a simple Apex snippet showing a Queueable that retries API calls without choking limits:

public class CalloutQueueable implements Queueable {
    private String payload;
    public CalloutQueueable(String body) {
        this.payload = body;
    }
    public void execute(QueueableContext context) {
        if (Limits.getCallouts() < Limits.getLimitCallouts()) {
            HttpRequest req = new HttpRequest();
            req.setEndpoint('callout:ExternalAPI');
            req.setMethod('POST');
            req.setBody(payload);
            new Http().send(req);
        } else {
            // re-queue if we’re out
            System.enqueueJob(new CalloutQueueable(payload)); 
        }
    }
}

Notice the pattern: don’t fail loudly. Queue politely. 🧠 

SMALL BITES, BIG WINS

BATCH LIKE A PRO

Batching is about grouping operations so you reduce chattiness. 📦️ 

Instead of 1,000 tiny requests, you send ten bigger ones.

This principle applies whether Salesforce is making outbound calls or being hammered inbound. 🔨 

Salesforce-native batching tools:

🧱 Batch Apex – Splits heavy jobs into 200-record chunks. Perfect for data enrichment or mass updates.

📈 Bulk API 2.0 – Inbound savior for large data loads. Up to 150 million records/day if used correctly.

😄 Composite API – Batching in disguise: lets you pack multiple REST requests into one call.

Example: imagine updating 500 contacts with an external CRM.

Instead of hammering the API with 500 separate requests, use Composite API to bundle them:

POST /services/data/v61.0/composite

  "allOrNone" : false,
  "compositeRequest" : [
    { "method" : "PATCH", "url" : "/sobjects/Contact/003...", "body" : {"Email":"[email protected]"} },
    { "method" : "PATCH", "url" : "/sobjects/Contact/003...", "body" : {"Email":"[email protected]"} }
  ]
}

Small bites keep limits happy. Big wins keep admins happy. 🥰 

RETRY WITHOUT RAGE

BACKOFF, BUDDY

Retrying an API call after failure is smart. 💯 

Retrying it immediately, 1,000 times per second, is how you end up on Salesforce’s naughty list.

Backoff strategies give breathing room between retries. 😮‍💨 

The gold standard here is exponential backoff: after each failure, you double the wait time before retrying (e.g., 2s → 4s → 8s).

This avoids thundering herds and gives Salesforce’s shared resources time to recover.

In Apex, a backoff-friendly retry might look like this (conceptualized, since Apex can’t sleep): 👇️ 

public class BackoffHelper {
    public static void enqueueWithBackoff(String payload, Integer attempt) {
        Integer delay = Math.min(60000, (Integer)Math.pow(2, attempt) * 1000); 
        System.scheduleBatch(new CalloutBatch(payload, attempt+1), delay);
    }
}

Key takeaway: don’t hammer the door down. Knock, wait, then knock again a little later.

CLIENT VS. SERVER VIEW

TWO SIDES OF LIMITS

Salesforce wears two hats in integrations: client (making outbound calls) and server (receiving inbound).

Each role comes with unique API limit challenges. 🧩 

As client (outbound):

❌ You’ll hit callout limits (100 per transaction) and overall API request caps.

✅ Queues + backoff strategies help prevent blowing through governor limits.

🤝 Composite API is your friend for reducing chattiness.

As server (inbound):

↪️ You face 24-hour rolling limits (per license type).

⚡️ Bulk API and Streaming APIs (like Platform Events) can buffer high volume.

🏗️ Architect for “graceful degradation”: if a partner floods you, fail fast and retry later instead of melting down.

This dual perspective matters. Architects who only optimize one side often leave nasty bottlenecks on the other.

HEATLHY ORG, HAPPY TEAM

SCALING WITHOUT TEARS

API limits aren’t bugs. It’s just Salesforce politely saying, “Slow down, champ.”

The orgs that thrive under heavy integrations aren’t the ones who hack around limits; they’re the ones who architect for them up front. 🙌 

Key best practices:

💃 Design async first – If it doesn’t need to be synchronous, don’t force it.

💃 Batch aggressively – Both inbound and outbound.

💃 Respect limits – Monitor usage (Event Monitoring, Shield, or even free reports).

💃 Implement backoff – Avoid retry storms.

💃 Think elastic – Assume partners (and your own business growth) will keep sending more data tomorrow than today.

When you queue smartly, batch cleanly, and back off gracefully, your Salesforce org doesn’t just survive high-volume integrations.

It thrives! 🪴 

And your admins don’t have to explain to executives why “the API lights are on, but nobody’s home.”

SOUL FOOD

Today’s Principle

and now....Salesforce Memes