Rate limits vary by plan. All limits are per API key. To prevent abuse, Unlimited Plans are subject to our Fair Use Policy.

How the window works

This works as a rolling window, not a fixed daily reset. The moment you make your first request, a 5-hour window opens. Everything you use for the next 5 hours draws from the same pool — the figure in your plan's row above. When the window closes, the limit resets, and your next request kicks off a fresh 5-hour window.

A $97 account can therefore spend all 15k enrichment records in the first minute and then wait out the rest of that window, or spread the same 15k evenly across the five hours. The weekly window works the same way — it rolls from your first request rather than resetting on a calendar day.

Nothing is scheduled, so there's no reset hour to plan around. get_account reports when each window resets, which is the exact moment your current pool refills — see Check where you stand below.

Hit and Misses

What counts as a request

Every API call counts toward the rate limit, regardless of whether it returns data — a not_found result is still a request. Each item of a batch counts separately, so a batch of 100 counts as 100 requests. The free account tools (get_account, get_billing, get_usage) never count toward the rate limit.

What counts as a miss

A lookup that finds nothing still counts as a request, but consumes no records and no tokens. Records are only consumed when data is actually returned, and are handed back if a later cap drops the result.

Check where you stand

Before assuming you've hit a wall, check your current position. get_account, get_billing, and get_usage are free — they never cost tokens.

get_account — live rate-limit standing

get_account returns a fair_use object that mirrors the tables above: enrich and search, each split into records and requests, over the 5h and 1w windows. Each window reports its cap, how much you've used, how much remains, and when it resets — so you can see exactly how much headroom is left and when the window rolls over.

"fair_use": {
  "enrich": {
    "records":  { "5h": { "limit": 15000, "used": 0, "remaining": 15000, "resets_at": null } },
    "requests": { "5h": { "limit": 75000, "used": 0, "remaining": 75000, "resets_at": null } }
  },
  "search": { "records": { "5h": { "limit": 7500, "used": 0, "remaining": 7500, "resets_at": null } } }
}

A resets_at of null means the window hasn't started counting yet (nothing used); once you make calls it carries the timestamp when that window resets.

get_usage — consumption history

get_usage shows how many calls you've actually made over a period, broken out by day plus a totals block — calls, with data, without data, and failed. Use it to spot bursts that are pushing you toward the 5-hour caps and to confirm which runs are driving your volume.

Ask your connected agent "check my MoltSets rate-limit headroom" and it will read these for you.

Staying within the limit

A few approaches to keep your usage within bounds:

Spread your automations out

If you're running scheduled tasks, split them across 2–4 runs per day rather than one large burst. Because the 5-hour window rolls from your first request, spacing runs at least five hours apart gives each one a fresh pool to draw from.

Use batching with pauses between batches

For high-volume operations — say, updating 10,000 leads — don't fire all requests at once. Instead:

Group your calls into batches of 100
Wait 2 seconds between each batch
Continue until all requests are processed

If you need help adapting your code to work within these limits, any AI coding assistant can help restructure your logic.

Rate limit errors

When you exceed a limit, the API returns 429 Too Many Requests with one of three codes:

Code	What ran out
fair_use_limit_exceeded	A Fair Use record window — the records columns in the tables above. On the free tier, also the one-time search trial.
fair_use_requests_exceeded	The 5-hour request window — every call attempted, hits and misses alike.
rate_limited	The burst guard, which fires on too many requests in too short a time regardless of your plan headroom.

{
  "error": {
    "code": "fair_use_limit_exceeded",
    "message": "Fair use record limit reached. Retry after the window resets."
  },
  "metadata": {
    "retry_after": 7200
  }
}

Fair Use 429s carry metadata.retry_after — seconds until the binding window unlocks — and the same value in a Retry-After header. Wait that long rather than guessing a backoff.

The exception is a limit that is a plan condition rather than a window: an exhausted free-tier search trial returns fair_use_limit_exceeded with an upgrade message and no Retry-After, because that grant never refreshes. Retrying will not clear it.

The request is not retried automatically — your client is responsible for handling 429 responses.

Batches return partial results, not a 429

When a batch runs past a Fair Use window, the items beyond your allowance are dropped unprocessed and the call still returns 200 with the results it did produce, plus an error block naming the cap that fired. That 200 carries metadata.retry_after and a Retry-After header, exactly like the single-call 429 — a half-succeeded batch is the response most likely to be retried in a tight loop, so read the header before resending. Resend only the items that were dropped.

Handling rate limits

When a 429 carries Retry-After, honour it — it is the exact number of seconds until the binding window unlocks, and retrying sooner just burns request quota. Where there is no header, fall back to exponential backoff:

async function callWithBackoff(fn, retries = 4) {
  for (let i = 0; i < retries; i++) {
    try {
      return await fn();
    } catch (err) {
      if (err.status !== 429 || i === retries - 1) throw err;
      await new Promise(r => setTimeout(r, Math.pow(2, i) * 200));
    }
  }
}

Batch endpoints where available (e.g. linkedin_to_mobile_phone supports up to 100 linkedin_urls per call) let you reduce total request count significantly.

Rate Limits