Instagram API Rate Limits

The honest answer: there is no published limit

The gateway does not count your requests per second, per minute or per day, and there is no header telling you how many calls remain in a window because no such window exists. This is not an oversight. The thing that meters usage here is the credit balance, and a request counter on top of it would only add a second, less predictable meter. If you want a hard ceiling on spend, set it in your own scheduler, or keep the balance low deliberately.

What genuinely bounds you

Three things. First, your credit balance: when it drops below the endpoint's cost, requests return 402 rather than queueing. Second, a 25 second timeout on each individual scrape; a request that exceeds it returns 504 UPSTREAM_TIMEOUT, uncharged. Third, upstream capacity, which is the real constraint under a large burst and the one you cannot see from your side. None of these produce a 429 on a keyed request.

What a burst actually looks like

Because nothing is there to reject you, a burst does not fail fast. Latency climbs first, and then individual scrapes start crossing the 25 second budget and returning 504. Those are free, so a burst that partially fails costs you only the successful portion. The correct response is a bounded worker pool plus exponential backoff on 500 and 504, the same policy the errors page describes. We do not publish a recommended concurrency, because the useful width depends on the endpoint and on upstream conditions rather than on a limit we enforce: start narrow, watch the share of 500 and 504 responses your own traffic returns, and widen only while that share stays flat.

Concurrency cannot overspend your balance

Credit deduction is a single atomic database operation that decrements only when the balance still covers the cost, so parallel requests cannot each read the same balance and collectively spend past zero. The requests that arrive after the balance runs out receive 402 and are not charged. You can therefore run a wide worker pool without building a distributed spending lock of your own.

A bounded pool instead of a rate limiter

Because there is no window to respect, the useful control is concurrency rather than requests per second. This drains a queue of handles at a fixed width, which keeps latency stable and makes throughput a number you choose rather than one you discover.

async function pool(items, width, worker) {
  const queue = [...items];
  const results = [];

  await Promise.all(
    Array.from({ length: width }, async () => {
      while (queue.length) {
        const item = queue.shift();
        results.push(await worker(item));
      }
    }),
  );

  return results;
}

const profiles = await pool(handles, 12, (handle) =>
  call("/v1/instagram/profile", { handle }),
);

Repeated lookups are billed

A successful lookup is billed at the endpoint's rate even when InScrape serves a locally cached result. Check credits_charged on each response for the actual charge; failed requests and documented no-charge responses remain free.