Rate Limits

ZoomInfo enforces rate limits on all authenticated API requests to ensure stability and fair resource allocation across all customers. If you send too many requests in a short period, you will receive 429 Too Many Requests responses.

Rate limit tiers

Your rate limits are determined by your ZoomInfo subscription and are visible on every API response via the X-RateLimit-Limit-* headers.

For example, a Standard plan allows up to 25 requests per second, while also enforcing 54,000 requests per hour and 648,000 requests per day. This allows applications to handle short bursts of traffic while preventing sustained high-volume usage.

Hourly and daily limits are intentionally set below the theoretical per-second maximum to prevent sustained abuse while still accommodating legitimate traffic spikes.

To request a higher limit, see Requesting a limit increase.

Retry Guidance: When a request returns 429 Too Many Requests, inspect the response to determine which rate limit was exceeded. For example, if the hourly limit is exhausted and the server indicates a Retry-After value of 719 seconds, pause requests for 719 seconds (about 12 minutes) before retrying. For per-second limits, use exponential backoff instead of fixed retry intervals.

How rate limits work

Every API request is evaluated against three independent windows simultaneously:

All three windows must have remaining capacity for a request to succeed. If any window is exhausted, the request is rejected with a 429 response.

ZoomInfo uses a sliding window counter algorithm for the per-hour and per-day limits. Unlike a fixed window that resets abruptly at set intervals — allowing a double burst at the boundary — the sliding window carries a decaying contribution from the previous window, ensuring smooth and consistent enforcement.

Response headers

ZoomInfo returns quota headers on every API response so you can monitor usage proactively and throttle before hitting a limit.

On every response

On 429 responses only

---

Handling 429 responses

When you receive a 429 response:

1. Check X-RateLimit-Rejected-Bucket to identify which window was breached: second, hour, or day.
2. Read Retry-After for the exact number of seconds to wait before retrying.
3. Read X-RateLimit-Reset for the Unix epoch timestamp of when the breached window resets — useful for scheduling work after a quota boundary.
4. Do not retry immediately. The Retry-After value may be hundreds or thousands of seconds if an hourly or daily quota is exhausted.

Example 429 response

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 25
X-RateLimit-Remaining: 25
X-RateLimit-Limit-Second: 25
X-RateLimit-Remaining-Second: 25
X-RateLimit-Limit-Hour: 54000
X-RateLimit-Remaining-Hour: 0
X-RateLimit-Limit-Day: 648000
X-RateLimit-Remaining-Day: 94000
X-RateLimit-Rejected-Bucket: hour
X-RateLimit-Reset: 1744246800
Retry-After: 719

The hour window was exhausted. Wait 719 seconds (~12 minutes) before retrying, or schedule work after the Unix timestamp 1744246800.

Retry strategy by window

Implement Exponential Backoff

Do not use a fixed 1-second retry loop. The Retry-After value may be 719 seconds or more when an hourly quota is exhausted. Ignoring it and retrying immediately will not succeed.

---

Proactive throttling

Rather than waiting for a 429, read the Remaining headers on every response and slow down before hitting a limit:

X-RateLimit-Remaining-Second: 2   → slow down immediately
X-RateLimit-Remaining-Hour: 120   → reduce throughput for the rest of this hour
X-RateLimit-Remaining-Day: 400    → schedule lower-priority work for tomorrow

Distributing requests evenly across the hour and day — rather than front-loading them — is the most reliable way to avoid quota exhaustion.

---

Burst behavior

First use

On your first hour of API usage, the full hourly quota is available as an instant burst. There is no prior usage history to penalize.

Steady state

From the second hour onward, the sliding window carries a decaying contribution from the previous hour. If you exhaust your hourly quota, the next hour's slots open gradually — not all at once at the boundary — as the previous hour's contribution decays.

Per-second boundary protection

Sending requests across a second boundary does not give you a burst advantage. Requests from the previous second count fully against the current second's limit. Sending 25 requests in the last 500ms of one second and 25 more in the first 500ms of the next results in requests 26–50 being rejected.

---

Migrating from legacy headers

If your integration uses the old header names, update your code as follows:

Semantics change: X-RateLimit-Reset now reflects when your current request volume drops below the limit under the sliding window algorithm, rather than when the fixed rate-limit window expires. The value is a Unix epoch timestamp; in most cases it will be earlier than before, since you no longer have to wait for the full window to roll over.

---

Requesting a limit increase

If your use case requires higher throughput than your current package provides:

1. Contact your ZoomInfo account team or email us at [email protected].
2. Provide your Tenant ID and the desired per-second value.
3. New limits take effect within 24 hours of the change being applied.