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: AhaSend
providerId: ahasend
generated: '2026-08-30'
method: searched
source: https://ahasend.com/docs/api-reference/rate-limits
sources:
  - https://ahasend.com/docs/api-reference/rate-limits.md
  - https://ahasend.com/docs/changelog.md
  - openapi/_original/ahasend-openapi-v2.yaml
created: '2026-05-04'
modified: '2026-08-30'
limit_count: 8
tags:
  - Email
  - Transactional Email
  - Rate Limiting
  - Quotas
  - Throttling
description: >-
  AhaSend's published API rate limits and hourly sending limits, read from the rate-limits
  reference and the product changelog on 2026-08-30. This artifact REPLACES a 2026-05-04
  scaffold whose per-tier request limits were invented defaults.
scope_note: >-
  Request rate limits are enforced PER ACCOUNT, not per API key — every key on an account shares
  one quota. Hourly sending limits are enforced per account and graduate with plan and sending
  history.
headers:
  limit: null
  remaining: null
  reset: null
  retryAfter: Retry-After
  policy: null
  note: >-
    AhaSend documents NO X-RateLimit-*/RateLimit-* response headers. The rate-limits page tells
    clients to "check the response headers for rate limit information" but never names a header,
    and the OpenAPI declares a response header on only three operations — a `Retry-After` on the
    429 of the three statistics endpoints. An agent therefore cannot read its remaining budget
    from a normal 2xx response; it can only discover the ceiling by hitting it. This is the
    single largest runtime-signalling gap in an otherwise unusually complete developer surface.
responseCodes:
  throttled: 429
  quotaExceeded: 429
  serviceUnavailable: 503
error_body:
  content_type: application/json
  example: '{"message": "Too many requests, rate limited."}'
algorithm: >-
  Sliding window that resets every second, per AhaSend's rate-limits documentation.
limits:
  - name: Standard API endpoints — sustained rate
    scope: account
    metric: requests_per_second
    limit: 100
    burst: 200
    timeFrame: second
    applies:
      - /v2/accounts/*
      - /v2/accounts/{account_id}/api-keys/*
      - /v2/accounts/{account_id}/domains/*
      - /v2/accounts/{account_id}/messages/*
      - /v2/accounts/{account_id}/suppressions/*
      - /v2/accounts/{account_id}/routes/*
      - /v2/accounts/{account_id}/webhooks/*
      - /v2/accounts/{account_id}/smtp-credentials/*
  - name: Statistics endpoints — sustained rate
    scope: account
    metric: requests_per_second
    limit: 1
    burst: 1
    timeFrame: second
    applies:
      - /v2/accounts/{account_id}/statistics/transactional/deliverability
      - /v2/accounts/{account_id}/statistics/transactional/bounce
      - /v2/accounts/{account_id}/statistics/transactional/delivery-time
    note: No burst allowance. These are the only operations whose 429 declares a Retry-After header.
  - name: Pro plan hourly sending — starting tier
    tier: pro
    scope: account
    metric: messages_per_hour
    limit: 1000
    timeFrame: hour
    note: Steps up to 5,000 then 10,000 per hour as sending reputation and history build (July 2026 changelog).
  - name: Pro plan hourly sending — established tier
    tier: pro
    scope: account
    metric: messages_per_hour
    limit: 10000
    timeFrame: hour
  - name: Max plan hourly sending — starting tier
    tier: max
    scope: account
    metric: messages_per_hour
    limit: 2000
    timeFrame: hour
    note: Steps up to 20,000 then 100,000 per hour (July 2026 changelog).
  - name: Max plan hourly sending — established tier
    tier: max
    scope: account
    metric: messages_per_hour
    limit: 100000
    timeFrame: hour
  - name: Legacy metered plans hourly sending
    tier: legacy
    scope: account
    metric: messages_per_hour
    limit: 500
    timeFrame: hour
    note: Legacy metered plans keep a 500 to 1,000 to 2,000 per hour curve.
  - name: SMTP relay per-message and per-connection limits
    scope: connection
    metric: composite
    limit: null
    timeFrame: null
    values:
      recipients_per_message: 50
      max_message_size_mb: 20
      messages_per_connection: 10000
      idle_timeout_seconds: 60
    note: Published in AhaSend's llms.txt and the SMTP server documentation; applies to send.ahasend.com and send-us.ahasend.com.
policies:
  - name: Backoff Strategy
    description: >-
      AhaSend's documentation prescribes exponential backoff with jitter on a 429 and ships
      JavaScript and Python reference implementations on the rate-limits page.
  - name: Higher limits by review
    description: >-
      Higher rate limits are available after a manual review; AhaSend directs high-volume senders
      to support@ahasend.com.
  - name: Prefer webhooks over polling
    description: >-
      AhaSend explicitly recommends webhooks instead of polling, and caching for statistics, as
      the way to stay inside the 1 request/second statistics ceiling.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com