Skip to main content
AutosnapAI enforces rate limits per API key to protect the platform. Every authenticated request is counted against four time windows — per minute, per hour, per day, and per month — and a request is rejected with 429 as soon as it would exceed any one of them.

How limits are grouped

Limits are applied per endpoint class, not per individual URL. Most endpoints have their own class (and therefore their own independent counter), but some related endpoints share a single counter. Requests to endpoints in the same class draw from the same minute/hour/day/month allowance.
The counter key is (your API key's account, endpoint class). Path parameters never fragment the counter — for example, every GET /v1/dealers/setup/{setup_id} poll, regardless of setup_id, counts against the same status-poll bucket.

Per-endpoint limits

The named endpoints below each have their own dedicated counter. The limits shown are your account’s current allocation; they are set per account and may differ for other clients. Contact support@autosnaplive.com if you need them adjusted.
POST /v1/dealers/setup is intentionally capped low (75/day) — each call spawns a background onboarding job. If you onboard dealers in bulk, space out your setup calls or contact support to raise this limit before a large rollout. The status-poll endpoint is far more generous (200/min) so you can poll a setup’s progress freely.

Default tier (everything else)

Any endpoint not named above falls into the default tier: Default-tier endpoints share one combined counter. All default-tier endpoints you call draw from the same allowance — for example, requests to /v2/recalls and /v2/safety-ratings in the same minute both count against the same 100/minute default bucket. Endpoints in the default tier include:
  • GET /v1/dealers (list) and other unmapped /v1/* endpoints
  • /v2 data reads such as recalls, safety ratings, complaints, fuel economy, VIN decode, dashboard, vault, dealership reviews, and embeddings status
(A few compute-heavier /v2 endpoints — semantic search, match-score, payment calculation, and similar-vehicle / history-report / market-comparable / incentive / window-sticker lookups — are in their own separate class rather than the default tier.)

Time windows

  • Minute, hour, and day are sliding windows — the count reflects the trailing 60 seconds / 60 minutes / 24 hours, continuously. There is no fixed reset boundary for these.
  • Month is a calendar month — it resets on the 1st of each month at 00:00 UTC. Note this differs from a rolling 30-day window: your monthly allowance refreshes on the 1st, not 30 days after your first request.
A blocked request does not consume budget — only successful requests increment the counters.

The 429 response

Exceeding any window returns HTTP 429 with this body:
The detail string reports the current count, the limit, and the specific window that was exceeded (minute, hour, day, or month). The first window to be exceeded is the one reported.

Test key quota

Test keys (as_test_...) have a separate monthly request quota configured per account, independent of the limits above. The quota varies by account — check your dashboard or contact your account manager. When exceeded, test calls return 429 but live keys continue to work normally:

Handling rate limits

  • When you receive a 429, back off and retry after a short delay
  • For 5xx errors, use exponential backoff with jitter
  • Use webhooks instead of polling for inventory changes
  • Cache responses locally and invalidate when webhooks notify you of changes
  • Use the max per_page value to minimize round trips