Rate Limits

Limits by Plan

Upgrade your plan in the developer portal.

Response Headers

Every API response includes the following headers so you can track your usage programmatically.

When You Hit the Limit

Once your daily or monthly quota is exhausted, the API returns 429 Too Many Requests with a JSON error body:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1743465600

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Daily rate limit exceeded. Resets at midnight UTC.",
    "reset_at": "2026-03-26T00:00:00Z"
  }
}

Your client should inspect X-RateLimit-Remaining proactively and back off before hitting zero, rather than relying on 429 responses to throttle.

Check Your Usage

You can query your current usage at any time via the GET /v1/auth/usage endpoint:

curl https://api.cardapi.dev/v1/auth/usage \
  -H "Authorization: Bearer ck_live_xxx"

{
  "data": {
    "daily_used": 42,
    "daily_limit": 100,
    "monthly_used": 310,
    "monthly_limit": 3000,
    "tier": "free"
  }
}

This endpoint does not itself count against your quota.

Best Practices

• Cache responses on your end

  Card data changes infrequently (typically once per day after our 3 AM ET scrape). Cache responses for at least an hour to avoid redundant calls.

• Use webhooks for change notifications

  Enterprise customers can subscribe to card.updated and card.created events instead of polling. This eliminates most polling traffic entirely.

• Batch requests where possible

  Use the /v1/cards/compare endpoint to fetch multiple cards in a single request rather than calling /v1/cards/:id repeatedly.

• Monitor X-RateLimit-Remaining

  Read the rate limit headers on every response. If Remaining drops below 10% of your limit, slow your request rate to avoid hitting the cap.

• Upgrade before you hit limits

  If you regularly approach your daily limit, upgrade your plan. Upgrade takes effect immediately and the higher limits apply to your next request.