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 HTTP429 (see error codes for the full list):
Retry strategy
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.Related pages
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
What happens when I exceed the rate limit?
What happens when I exceed the rate limit?
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.Are rate limits per key or per organization?
Are rate limits per key or per organization?
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.
Why did a signals request get rate limited when I was under my plan limit?
Why did a signals request get rate limited when I was under my plan limit?
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.What about long-running operations like lead lists and exports?
What about long-running operations like lead lists and exports?
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.
How do I avoid hitting rate limits?
How do I avoid hitting rate limits?
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.Do rate-limited requests consume credits?
Do rate-limited requests consume credits?
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.Can I request a higher rate limit?
Can I request a higher rate limit?
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.
How does the rolling 60-second window work?
How does the rolling 60-second window work?
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.