specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: RudderStack
providerId: rudderstack
generated: '2026-08-13'
method: searched
source: >-
  https://www.rudderstack.com/docs/api/user-suppression-api/,
  https://www.rudderstack.com/docs/api/http-api/,
  https://www.rudderstack.com/pricing/
created: '2026-05-08'
modified: '2026-08-13'
reconciled: true
tags:
  - Customer Data Platform
  - CDP
  - Event Streaming
  - Rate Limiting
  - Quotas
  - Throttling
limit_count: 5
description: >-
  RudderStack publishes very little runtime rate-limit information. The HTTP
  tracking API documents a 429 "Too many requests" status but NO request-per-second
  cap, and the only numeric per-API rate limit anywhere in the documentation is on
  the User Suppression API, expressed as hourly token budgets. The real commercial
  constraint is the monthly event quota attached to the plan tier. Payload limits
  (32 KB per call, 4 MB per batch, 200-level JSON nesting) are documented and hard.
headers:
  published: false
  x_ratelimit: []
  ietf_ratelimit: []
  retry_after: false
  note: >-
    THE MOST IMPORTANT FINDING HERE. RudderStack documents no rate-limit response
    headers of any kind — no X-RateLimit-Limit/Remaining/Reset, no RFC-draft
    RateLimit-*, and no Retry-After on a 429. An agent or SDK cannot read its
    remaining budget or a server-supplied backoff interval from any response; the
    only runtime signal is the 429 itself. Exponential backoff is the only viable
    client strategy.
responseCodes:
  throttled: 429
  payloadTooLarge: 413
  badRequestOnOversize: 400
limits:
  - name: User Suppression API — suppression tokens
    scope: workspace
    api: User Suppression API (POST /v2/regulations)
    metric: tokens
    limit: 4000
    window: hour
    timeFrame: hour
    documented: true
    source: https://www.rudderstack.com/docs/api/user-suppression-api/
    notes: >-
      1 user = 1 token for a suppression request. Published verbatim by RudderStack
      as a table on the User Suppression API page.
  - name: User Suppression API — deletion tokens
    scope: workspace
    api: User Suppression API (POST /v2/regulations with deletion)
    metric: tokens
    limit: 200000
    window: hour
    timeFrame: hour
    documented: true
    source: https://www.rudderstack.com/docs/api/user-suppression-api/
    notes: >-
      Token cost for deletion is users × destinations — m users across n
      destinations consumes m*n tokens. A 200-destination workspace exhausts the
      budget at 1,000 users per hour.
  - name: HTTP tracking API throttling
    scope: source
    api: HTTP API ({DATA_PLANE_URL}/v1/*)
    metric: requests
    limit: null
    window: null
    documented: false
    status_on_exhaustion: 429
    source: https://www.rudderstack.com/docs/api/http-api/
    notes: >-
      HONEST ZERO. RudderStack documents the 429 response but publishes no numeric
      request-rate cap for event ingest. Self-hosted rudder-server deployments
      inherit only the limits the operator configures.
  - name: Free plan monthly events
    scope: workspace
    metric: events
    limit: 250000
    timeFrame: month
    window: month
    documented: true
    source: https://www.rudderstack.com/pricing/
  - name: Growth plan monthly events (entry rung)
    scope: workspace
    metric: events
    limit: 1000000
    timeFrame: month
    window: month
    documented: true
    source: https://www.rudderstack.com/pricing/
    notes: >-
      Published volume ladder runs 1M / 3M / 5M / 7M / 10M / 25M, then sales-quoted.
      Enterprise volume is quoted.
payload_limits:
  - name: Maximum event size
    limit: 32 KB
    scope: per call
    status_on_exceed: 400
    source: https://www.rudderstack.com/docs/api/http-api/
  - name: Maximum batch size
    limit: 4 MB
    scope: per batch (32 KB per call within it)
    status_on_exceed: 400
    source: https://www.rudderstack.com/docs/api/http-api/
  - name: Maximum JSON nesting depth
    limit: 200 levels
    scope: per event payload
    status_on_exceed: rejected at ingestion with error feedback
    source: https://www.rudderstack.com/docs/api/http-api/
    notes: Objects and arrays both count toward the depth.
pagination_caps:
  - api: Data Catalog / Tracking Plan / Event Audit
    max_pages: 50
    note: >-
      Not a rate limit, but a hard result-set ceiling — offset pagination returns a
      maximum of 50 pages, so a large catalog cannot be fully enumerated without
      filtering.
  - api: Audit Logs
    per_page_max: 100
    note: Cursor pagination, per_page between 1 and 100, default 100.
downstream:
  note: >-
    Destination throughput is bounded by each destination's own rate limits, which
    RudderStack respects per connection. Enterprise customers can set P95 latency
    alert thresholds per Event Stream destination (GA 2026-02-27).
detail: conventions/rudderstack-conventions.yml