Skip to main content
Rate limits are enforced per API key on a .

Limits by plan

Signals, audiences and the tighter sub-limit

Endpoints under /v1/signals/* and /v1/segments/* carry an additional per-key limit on top of your plan limit. These queries scan the full detection corpus and are far heavier than a domain lookup. A 429 from this limiter identifies itself in the error details:
The free signal types index is exempt from the sub-limit — it returns metadata only.

Response headers

Every API response includes rate limit headers:

How to handle rate limits

When you exceed the limit, the API returns HTTP 429 (see error codes for the full list):

Retry strategy

Use the Retry-After header to implement exponential backoff. Wait the specified number of seconds before retrying.

Best practices

Cache responses

Tech stacks don’t change every minute. Cache domain lookups for at least 24 hours.

Use batch endpoints

/v1/technologies/lookup and /v1/companies/batch let you look up multiple items in a single request.

Monitor usage

Check /v1/usage to track request counts and credit consumption.

Authentication

Set up your API key for Bearer token authentication.

Credits

Credit costs per endpoint and plan details.

Errors

Error codes including 429 rate limit responses.

Frequently asked questions

The API returns HTTP 429 with a Retry-After header indicating how many seconds to wait. Your request isn’t charged credits. Wait the specified time and retry. See errors for the full error response format.
Per API key, on a rolling 60-second window. If you hold several keys, each has its own allowance — so splitting production and staging across separate keys also isolates their rate limits. Credits, by contrast, are reported and pooled at the account level. Create and manage keys in the dashboard under Settings > Developers.
Signals and audience endpoints have a second, tighter per-key limit — 10, 30 or 60 requests per minute depending on plan — because each call fans out into heavy scans across the detection corpus. A 429 from that limiter carries "scope": "signals" in error.details. Space these calls out, or cache their results, which is safe since the underlying data refreshes on a crawl cadence rather than continuously.
Lead lists run as a background job, so the create call returns immediately and you poll for completion rather than holding a connection open — rate limits barely matter. Signal CSV exports and audience reports run synchronously and can take several seconds; a query exceeding the 30-second server-side limit returns a 503 telling you to narrow it, and is never retried automatically.
Cache domain lookups for at least 24 hours (tech stacks don’t change that often). Use batch endpoints like /v1/companies/batch and /v1/technologies/lookup to process multiple items in one request. Monitor your usage with the free /v1/usage endpoint.
No. When the API returns HTTP 429, your request isn’t charged any credits. You only pay credits for successful responses. Wait the number of seconds in the Retry-After header and resend your request.
Pro and Scale both run at 300 requests per minute; Enterprise raises that to 1,000, and lifts the signals sub-limit from 30 to 60. If you need more throughput than that, contact TechnologyChecker — Enterprise plans include custom request quotas alongside higher credit allocations. Visit technologychecker.io to discuss your requirements.
Instead of resetting your request count at fixed intervals, the API uses a sliding window. Each request’s timestamp is tracked, and the count includes only requests from the last 60 seconds. This prevents burst traffic at window boundaries and gives you a steady, predictable request allowance.