[Deprecation] Smoother API rate limiting and the end of the burst headers

Starting October 19, 2026, we’re rolling out a new rate limiter for the Core API, with all companies updated by October 31. Your rate limit stays the same, but we’re changing how your requests refill.

What’s changing

Today, your rate limit resets all at once at the end of each one-minute window, with a separate burst allowance that takes 10 minutes to replenish. The new limiter replaces both with a single allowance that refills continuously at your rate limit, so at 100 requests per minute you get back about one request every 0.6 seconds instead of all 100 at the start of the next window. This removes the cliff at the end of each window, which means an integration that spreads its requests out at its rate limit can run indefinitely without waiting for a reset, and the wait after a 429 is now usually a few seconds rather than up to a minute (429 responses still don't count against your limit). Short spikes are still absorbed: while you send fewer requests than your limit allows, unused capacity builds up and a spike can use it. Treat this as a safety margin rather than an allowance to plan around, since its size isn't guaranteed and may change as we tune the limiter, so please don't build integrations that depend on a specific burst size.

Deprecating the burst headers

Until February 1st, 2027, we'll keep sending x-ratelimit-burst-limit and x-ratelimit-burst-remaining with real values, with two differences from today:

• Burst is used first. x-ratelimit-burst-remaining counts down while x-ratelimit-remaining stays at your limit. Once the burst is gone, x-ratelimit-remaining starts counting down.
• x-ratelimit-burst-limit may not equal half your plan's rate limit.

If your integration stops sending requests when x-ratelimit-burst-remaining reaches 0, it will keep working, but it will stop earlier than it needs to.

After February 1, 2027, both burst-related headers will be removed from all responses. View full header details here.

What to do before February 1, 2027:

• Pace requests with x-ratelimit-remaining and pause when it reaches 0
• On a 429, wait retry-after seconds before retrying
• Spread requests out rather than sending them all at the start of each minute. With continuous refill, steady pacing gets you the most throughput.
• Stop reading the burst headers, x-ratelimit-burst-limit and x-ratelimit-burst-remaining
   

Questions or concerns about your integration? Please reply in the comments!