Rate Limiting Basics for Follow Up Boss API

What is API rate limiting and why does Follow Up Boss use it?

An API rate limit is a ceiling on how many requests a single client can make in a given time window. When your code or integration crosses that ceiling, the server stops processing requests temporarily and returns an error — rather than slowing down for everyone else on the platform.

Follow Up Boss is a multi-tenant SaaS platform shared by thousands of real estate teams. Without rate limits, a single runaway integration — a misconfigured sync script, a bulk import gone wrong, or an infinite retry loop — could consume server capacity and degrade response times for every other account on the platform. Rate limiting is the safeguard that prevents that.

From a developer's perspective, rate limits are also a useful forcing function. They push you toward more efficient patterns: batching writes instead of one-at-a-time calls, subscribing to webhooks instead of polling, and building retry logic rather than fire-and-forget HTTP calls. Integrations that respect rate limits tend to be more resilient overall.

The exact request-per-minute threshold Follow Up Boss applies can change as the platform scales. Always check the current values in the official docs at followupboss.com/api-docs rather than relying on any number you read in a third-party article — including this one.

What happens when you hit the Follow Up Boss API rate limit?

When your integration exceeds the rate limit, the FUB API responds with HTTP 429 Too Many Requests. The response body typically includes a message explaining what happened, and the response headers may include a Retry-After value that tells your code exactly how many seconds to wait before trying again.

A 429 is not a permanent failure — it is a temporary pause signal. The correct response is to stop sending requests immediately, wait the indicated duration (or a calculated backoff interval if no Retry-After header is present), and then resume. Continuing to hammer the API after receiving a 429 does not help: it burns your remaining quota for the window and may result in longer cooldown periods.

Here is what a typical 429 response looks like:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{
  "errorCode": "RATE_LIMIT_EXCEEDED",
  "message": "Too many requests. Please slow down and retry after the indicated period."
}

Your integration should read the Retry-After header and pause for at least that many seconds. If the header is absent, fall back to exponential backoff (covered below).

How do you handle a 429 Too Many Requests error from the FUB API?

Handling a 429 correctly requires three things: detecting it, pausing with the right delay, and retrying with appropriate limits. Here is a step-by-step approach:

1. Detect the status code. Check the HTTP status of every API response. Do not assume success — always read the status code before processing the body.
2. Read the Retry-After header. If present, wait exactly that many seconds before retrying. This is the safest and most respectful option.
3. Fall back to exponential backoff with jitter if Retry-After is absent (see the section below).
4. Limit the number of retries. After three to five attempts, log the failure and surface it for human review rather than retrying indefinitely. An integration that loops forever on a 429 will block your queue and never self-heal.
5. Use a job queue. Rather than retrying inline (which blocks the current thread), push failed requests into a retry queue with a scheduled delay. Libraries like BullMQ (Redis-backed) handle this elegantly — you can set a backoff policy at the queue level so every job automatically waits between attempts.

What is exponential backoff and how does it apply to the FUB API?

Exponential backoff is a retry strategy where the wait time between attempts doubles (or increases by a configurable multiplier) with each failed attempt. Adding random jitter — a small random offset applied to each delay — prevents a "thundering herd" problem where many clients resume simultaneously and immediately hit the rate limit again.

The formula is: delay = base * (2 ^ attempt) + randomJitter

For example, with a 1-second base and up to 3 seconds of jitter:

• Attempt 1 failure: wait ~1–4 seconds
• Attempt 2 failure: wait ~2–5 seconds
• Attempt 3 failure: wait ~4–7 seconds
• Attempt 4 failure: wait ~8–11 seconds

Here is pseudocode illustrating exponential backoff with jitter for a FUB API call:

// Exponential backoff with jitter — pseudocode
async function callFubApiWithRetry(requestFn, maxAttempts = 5) {
  const BASE_DELAY_MS = 1000;   // 1 second
  const MAX_JITTER_MS = 2000;   // up to 2 seconds of random jitter

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await requestFn();

    // Success — return immediately
    if (response.status !== 429) {
      return response;
    }

    // Rate limited — calculate how long to wait
    const retryAfterHeader = response.headers.get('Retry-After');
    let waitMs;

    if (retryAfterHeader) {
      // Honor the server's guidance
      waitMs = parseInt(retryAfterHeader, 10) * 1000;
    } else {
      // Exponential backoff: 1s, 2s, 4s, 8s, 16s ...
      const exponentialDelay = BASE_DELAY_MS * Math.pow(2, attempt);
      const jitter = Math.random() * MAX_JITTER_MS;
      waitMs = exponentialDelay + jitter;
    }

    console.log(`Rate limited. Retrying in ${Math.round(waitMs / 1000)}s (attempt ${attempt + 1}/${maxAttempts})`);
    await sleep(waitMs);
  }

  throw new Error('Max retry attempts reached — giving up on this request');
}

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

This pattern is language-agnostic — the same logic applies whether you are writing Node.js, Python, Ruby, or any other language your integration uses. The key discipline is: never retry immediately, never retry indefinitely, and always add jitter.

How can you reduce Follow Up Boss API calls with webhooks?

Polling — periodically asking the API "has anything changed?" — is the single biggest cause of unnecessary API calls in FUB integrations. If you poll every 60 seconds to check whether a contact's stage changed, you are making one API call per minute whether anything changed or not. Scale that across a large contact database and you exhaust your rate limit quota on wasted requests.

Webhooks flip the model: Follow Up Boss pushes data to your endpoint the moment an event occurs. You receive a payload when a contact is created, a stage moves, a note is added, or a deal closes — with zero polling overhead. Your integration only does work when there is actually something to process.

Common FUB webhook events that replace polling patterns:

• personCreated — fires when a new lead enters FUB (replaces periodic "get new leads" polls)
• personUpdated — fires when any contact field changes (replaces "check for contact updates" polls)
• dealCreated / dealUpdated — fires on pipeline activity (replaces pipeline-status polls)
• noteCreated / taskCreated — fires on activity logging

To register a webhook, POST to /v1/webhooks with your HTTPS endpoint URL and the event type you want to subscribe to. Stand up a receiver that acknowledges the payload within a few seconds (return 200 immediately and do heavy processing asynchronously), and verify the optional payload signature if you configure a secret.

Polling vs. webhooks: rate limit impact at a glance

The pattern is clear: for anything time-sensitive, webhooks are not just more efficient — they are faster, too. Reserve polling for the cases where it genuinely makes sense: one-time historical imports, scheduled nightly sync jobs, or situations where webhooks are not available for the specific event type you need.

Best practices for staying within FUB API rate limits

Combining the patterns above into a set of concrete practices gives you a rate-limit-safe integration from day one:

1. Always check the official docs for current limits. Visit followupboss.com/api-docs before building your integration and again before going to production. Published limits can change, and your code should react to the actual 429 signal rather than hard-coding a requests-per-minute constant.
2. Implement exponential backoff with jitter on every API call path. Even if you never expect to hit the rate limit during development, production traffic patterns are different. Make retry logic the default, not an afterthought.
3. Replace polling loops with webhook subscriptions wherever possible. Audit your integration for any code that runs on a timer and calls the FUB API to check for changes. Convert those patterns to webhook listeners.
4. Batch updates when the API allows it. Some FUB endpoints accept multiple records per request. Where batching is supported, group your writes to reduce the total call count. For custom field updates across many contacts, grouping changes saves significant quota.
5. Throttle proactively with a token bucket or rate limiter in your own code. Libraries like bottleneck (Node.js) or ratelimit (Python) let you set a maximum requests-per-second in your client code, so you never get close to the server-side ceiling rather than relying on 429s to slow you down.
6. Queue and stagger bulk operations. When you need to import or update thousands of contacts, spread the work across time using a job queue with rate-aware concurrency settings. Sending thousands of requests in a burst is the fastest way to exhaust your quota.
7. Log every API response status code. Follow Up Boss does not provide a native API request log accessible to integrators. Your own logging is your only audit trail. Record status codes, timestamps, and endpoint paths so you can diagnose quota issues after the fact.
8. Test against a staging FUB account. Validate your retry logic deliberately — simulate a 429 in your test environment and confirm your backoff delays and retry limits behave as designed before going live.

How does Follow Up Ace stay within FUB API rate limits?

Building a production integration on top of any rate-limited API requires architectural decisions that go beyond basic error handling. Follow Up Ace's design reflects several years of running webhook-driven workflows at scale inside Follow Up Boss.

The most impactful choice is using FUB webhooks as the primary event source rather than polling. When a lead is created or updated in Follow Up Boss, a webhook fires immediately. Follow Up Ace receives that event, processes the contact's activity data, and writes enriched fields back to FUB — all without generating continuous polling calls. This means the bulk of Follow Up Ace's FUB interaction is write-side (updating fields) rather than read-side (repeatedly checking for changes), which uses quota far more efficiently.

The Ace Score fields — Ace Score (0–100), Ace Tier (Hot / Warm / Cool / Cold / Dormant), Ace Status, Ace Response Time, Ace Velocity Score, Ace Days Since Inbound, and Ace Preferred Channel — update in response to webhook-triggered events, not on a polling schedule. No event, no call. The system idles at near-zero API volume when your FUB account is quiet and scales up automatically when lead activity spikes.

For teams who want to extend that model with their own AI workflows, Follow Up Ace's agentic connector exposes 215 MCP tools that give Claude (via https://followupace.com/mcp) and ChatGPT (via https://followupace.com/api/mcp/sse/) natural-language access to your CRM. Rather than writing raw API calls for every agentic action — search contacts, log notes, run a pipeline report — you describe the task to your AI assistant and the MCP layer handles the API interaction, including rate-aware request management. See the Agentic page for a full breakdown of what those tools cover.

The Ace Trove adds a second layer: automated contact analysis that runs account-wide, scoring every lead based on engagement history, response time, and behavioral velocity. Because that scoring pipeline is triggered by webhook events and batched intelligently, it operates well within the FUB API's rate constraints even on accounts with large contact databases.

Common rate limit mistakes and how to avoid them

Understanding what goes wrong in practice is as useful as knowing the correct patterns. Here are the most common rate limit mistakes in FUB integrations:

• Retry loops without delay. Catching a 429 and immediately retrying in a tight loop is the most common mistake. You will receive nothing but 429 responses until the window resets, and you may trigger a longer cooldown. Always add a delay before retrying.
• Parallelizing bulk reads. When walking through all your contacts (e.g., for a full database export), fetching multiple pages simultaneously burns quota fast. Walk pages sequentially or use conservative concurrency limits.
• Polling to detect changes in near-real-time. Setting a 5-second poll interval to "monitor" a contact for changes is a webhook use case in disguise. Convert it.
• Not reading the Retry-After header. When FUB tells you exactly how long to wait, use that value. Guessing at a shorter delay risks another immediate 429.
• Hard-coding the rate limit value. Any number you hard-code today may be wrong six months from now when FUB adjusts limits. Code to the 429 signal, not to an assumed ceiling.

Further reading

• How to use the Follow Up Boss API docs — auth, endpoints, and best practices
• MCP protocol: the technology making real estate AI actually useful
• Follow Up Ace Agentic — 215 MCP tools for natural-language CRM control
• Ace Trove — webhook-driven lead scoring inside Follow Up Boss
• Follow Up Ace guides and tutorials
• More articles on Follow Up Boss integrations and AI