Rate limits

There are two kinds of limit: a daily ceiling on how many records you can pull, and per-second limits on the SkipTrace and Address Verification endpoints. Daily windows run midnight to midnight UTC.

Daily limits

Endpoint groupWindowCeiling
Property APIs24h1,000,000 property records / day
SkipTrace APIs24h1,000,000 matches / day

These are counted in records, not requests. One Property Search page can return up to 250 records, so the ceiling is 4,000 maximum-size requests — or 100,000 requests at a page size of 10, which is more typical for interactive use.

In practice most plans cannot buy enough credits to reach a daily ceiling; these limits realistically only come up on Enterprise property or skip plans.

Per-second limits

SkipTrace and Address Verification apply per-second limits, and those limits differ depending on whether you send an x-user-id header:

Keyed onAddress Verification
x-api-key10 requests / second, up to 1,000 addresses / second
x-user-id3 requests / second, up to 300 addresses / second per user

Sending x-user-id therefore does two things at once: it scopes a tighter limit to that individual user, and it stops one user's burst from consuming your account-wide allowance. For the current SkipTrace per-second figures, see the rate limiting reference.

Handling a 429

Exceeding a limit returns 429 with the scopes that tripped:

{
  "statusCode": 429,
  "error": "Too Many Requests",
  "message": "Daily usage limit exceeded for [PropertySearch, SkipTrace] scopes"
}

How to respond depends on which limit you hit, and the two need different handling:

  • A per-second limit is worth retrying. Back off exponentially with jitter and the request will succeed shortly.
  • A daily ceiling is not. Retrying will fail until the UTC window rolls over, so queue the work for the next window instead of spinning.

The message field tells you which scope was exceeded, so branch on that rather than treating every 429 the same way.

Staying under the limits

  • Take a count before running a search, so you never page through a result set larger than you expected.
  • Use ids_only for discovery and enrich only the records you keep.
  • Raise size for batch jobs — same records, far fewer requests.
  • For bulk work, prefer the purpose-built endpoints (Bulk SkipTrace takes 1,000 people per call) over looping a single-record endpoint.

Was this page helpful?