API Rate Limiting for MarTech Integrations
Why marketing integrations hit rate limits constantly
Marketing platforms (Meta Marketing API, Google Ads API, Salesforce, HubSpot) impose rate limits to protect their own infrastructure, and marketing integrations are especially prone to hitting them: bulk audience syncs, nightly full-account reporting pulls across hundreds of ad accounts, and real-time event forwarding (Conversions API calls per purchase) all generate bursty, high-volume traffic patterns that are exactly what rate limits are designed to throttle.
Common rate-limit models you'll actually encounter
Fixed window (e.g. Google Ads API: a fixed number of operations per account per day) resets all at once at a boundary, which can cause a burst right after reset. Sliding window / token bucket (common in Meta's Graph API) tracks usage continuously and refills capacity gradually, which smooths bursts but still throttles sustained high throughput. Concurrency limits (max simultaneous open connections, common in Salesforce) cap how many requests can be in-flight at once regardless of total volume. Each requires a different mitigation strategy — understanding which model a given API uses before writing a retry loop against it matters more than the retry logic itself.
async function callWithBackoff<T>(
fn: () => Promise<T>,
maxRetries = 5
): Promise<T> {
let attempt = 0;
while (true) {
try {
return await fn();
} catch (err: any) {
const isRateLimited = err.status === 429 || err.code === "RATE_LIMIT_EXCEEDED";
if (!isRateLimited || attempt >= maxRetries) throw err;
// Respect the platform's own Retry-After header when present
const retryAfterMs = err.headers?.["retry-after"]
? Number(err.headers["retry-after"]) * 1000
: Math.min(2 ** attempt * 1000, 30000) + Math.random() * 500; // exponential backoff + jitter
await new Promise((r) => setTimeout(r, retryAfterMs));
attempt++;
}
}
}Naive retry-on-429 without jitter makes outages worse, not better
Batching to reduce call volume, not just handle limits gracefully
Most marketing APIs offer batch endpoints specifically because they'd rather receive one request for 500 operations than 500 separate requests — Meta's Graph API batch requests, Google Ads API's mutate operations with multiple operations per call, Salesforce's Bulk API for large record volumes. Restructuring an integration to batch aggressively is almost always more effective than optimizing retry logic, since it reduces the actual number of rate-limited calls rather than just handling the consequence of making too many.
Queueing and backpressure for real-time event forwarding
Server-side Conversions API integrations (Meta CAPI, TikTok Events API) that forward purchase events in real time face a particular risk: a traffic spike (a flash sale) can generate events faster than the destination platform's rate limit allows. Rather than dropping events or blocking the checkout flow waiting on a slow downstream call, production integrations put events on a queue (a message broker, or even a simple database-backed job queue) and let a rate-limit-aware consumer drain it at a sustainable pace — decoupling event capture speed from forwarding speed entirely.
What's Next?
Rate limiting is one piece of building resilient marketing integrations — the related and equally important question is how your system decides whether to pull data on a schedule versus react immediately to a platform-pushed webhook.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.