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: FlightAware
providerId: flightaware
generated: '2026-09-10'
method: searched
source: >-
  https://www.flightaware.com/commercial/aeroapi/ (published tier limits) and a live
  unauthenticated probe of https://aeroapi.flightaware.com/aeroapi/airports/KIAH on 2026-09-10
  (response headers) plus openapi/ (declared responses)
created: '2026-05-04'
modified: '2026-09-10'
tags: [Aviation, Rate Limiting, Quotas, Throttling, Metering]
description: >-
  FlightAware's published rate limits for AeroAPI and Firehose. This REPLACES the 2026-05-04
  scaffold that previously stood here, which asserted invented per-minute quotas and a full
  X-RateLimit-* header family that AeroAPI does not return. The real posture is the opposite: limits
  are published as COMMERCIAL TIER ATTRIBUTES measured in result sets, and there is no runtime
  rate-limit signal at all.
limit_count: 6
unit: result set
unit_note: >-
  AeroAPI's limit and billing unit is the RESULT SET, not the HTTP request. A paginated call with
  max_pages > 1 consumes multiple result sets from one request, so request-per-second reasoning
  understates consumption.
limits:
  - tier: Personal
    name: Personal tier request rate
    scope: api-key
    metric: result_sets_per_minute
    limit: 10
    timeFrame: minute
    burst: null
    applies: [FlightAware AeroAPI]
    source: https://www.flightaware.com/commercial/aeroapi/
  - tier: Standard
    name: Standard tier request rate
    scope: api-key
    metric: result_sets_per_second
    limit: 5
    timeFrame: second
    burst: null
    applies: [FlightAware AeroAPI]
    source: https://www.flightaware.com/commercial/aeroapi/
  - tier: Premium
    name: Premium tier request rate
    scope: api-key
    metric: result_sets_per_second
    limit: 100
    timeFrame: second
    burst: null
    applies: [FlightAware AeroAPI]
    source: https://www.flightaware.com/commercial/aeroapi/
  - tier: Standard
    name: Historical endpoint monthly ceiling
    scope: account
    metric: result_sets_per_month
    limit: 500000
    timeFrame: month
    applies: [FlightAware AeroAPI history endpoints]
    source: https://www.flightaware.com/commercial/aeroapi/
  - tier: Premium
    name: Historical endpoint monthly ceiling
    scope: account
    metric: result_sets_per_month
    limit: 500000
    timeFrame: month
    applies: [FlightAware AeroAPI history endpoints]
    source: https://www.flightaware.com/commercial/aeroapi/
  - tier: all
    name: Firehose concurrent connections
    scope: account
    metric: concurrent_connections
    limit: 4
    timeFrame: concurrent
    applies: [FlightAware Firehose]
    source: https://www.flightaware.com/commercial/firehose/documentation/connection
headers:
  limit: null
  remaining: null
  reset: null
  retryAfter: null
  policy: null
  observed: >-
    NONE. A live unauthenticated request to https://aeroapi.flightaware.com/aeroapi/airports/KIAH on
    2026-09-10 returned HTTP 401 carrying only Date, Content-Type, Content-Length and Connection.
    No X-RateLimit-*, no RateLimit-*, no Retry-After.
responseCodes:
  throttled: undocumented
  quotaExceeded: undocumented
  serviceUnavailable: undocumented
  note: >-
    AeroAPI 4.30.0 declares NO 429 and no 5xx response on any of its 69 operations. There is no
    documented status code for exhaustion and no documented backoff signal.
runtime_visibility:
  in_band_signal: GET /account/usage
  operation_id: get_account_usage
  added_in: AeroAPI 4.30.0
  note: >-
    The only way an agent can observe its own consumption is to POLL the account usage endpoint. That
    is a meaningful improvement over nothing — it did not exist in 4.17.1 — but it is a separate,
    itself-billable call rather than a per-response header, so a client cannot see its headroom on
    the response that consumed it.
policies:
  - name: Cost is the real limit
    description: >-
      Because AeroAPI meters per result set with no request quota, the binding constraint for most
      consumers is spend, not throttling. `max_pages` is the single most cost-sensitive parameter in
      the API; there is no budget cap or spend guard in the contract.
  - name: Firehose reconnect
    description: >-
      Firehose publishes operational guidance rather than a rate limit: disconnect and reconnect if
      no message has arrived in 5 minutes, and resume with `pitr <epoch>` or
      `range <start> <end>` from the last received timestamp so no data is lost.
    source: https://www.flightaware.com/commercial/firehose/documentation/connection
gaps:
  - No rate-limit response headers of any kind.
  - No 429 declared in the contract and no documented status code on exhaustion.
  - No published backoff or Retry-After guidance for AeroAPI.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com