generated: '2026-09-10'
method: derived
source: >-
  openapi/fusebit-http-api-core-openapi.yml (FunctionRoutes.task schema and the 429 responses on
  putFunction / postFunctionBuild / getFunctionBuild) and
  https://fivequarters.github.io/q5/release-notes/fusebit-http-api/ (release 1.40.23).
provider: Fusebit
providerId: fusebit
checked: '2026-09-10'
summary: >-
  Fusebit published no plan-level API rate limits and no rate-limit response headers. What it DID
  publish, inside the contract itself, is a per-function task-queue admission control with concrete
  numeric defaults, plus a 429 on the module-build path. Those two are recorded below because they
  are real, published, numeric limits an integrator had to design around. Nothing here was observed
  on a live response: the API host no longer resolves (api.us-west-1.on.fusebit.io, NXDOMAIN,
  2026-09-10), so a live probe is impossible and none is claimed.
supersedes_note: >-
  This file replaces an API Evangelist scaffold dated 2026-05-04 that asserted free/professional/
  enterprise tiers with invented per-minute limits, monthly quotas and an X-RateLimit-* header family
  Fusebit never published. Those values were never sourced from Fusebit and have been removed.
limit_count: 2
headers_published: false
headers: []
headers_note: >-
  No RateLimit-*, X-RateLimit-* or Retry-After response header is declared anywhere in either
  published contract. A client can observe that it was throttled from the status code alone; it
  cannot see its remaining budget or a server-advised backoff. This is the single biggest runtime
  gap in the Fusebit rate-limit surface.
status_on_exhaustion: 429
status_history:
  - change: Rate-limited function executions changed from HTTP 503 to HTTP 429.
    version: 1.40.23
    date: '2022-11-01'
    source: https://fivequarters.github.io/q5/release-notes/fusebit-http-api/
limits:
  - scope: per-function
    surface: 'Fusebit Functions — task routes (v1)'
    name: maxPending
    limit: 1024
    unit: pending task executions
    window: concurrent (queue depth, not time-windowed)
    burst: null
    status_on_exhaustion: 429
    configurable: true
    description: >-
      A function route declared as a `task` route queues HTTP POSTs for asynchronous execution and
      answers 202 immediately with a `location` header pointing at the task status URL. Once the
      number of executions pending exceeds `maxPending`, further requests are rejected with 429 and
      are NOT scheduled. Default 1024; specify 0 to allow any number of pending requests.
    source: 'openapi/fusebit-http-api-core-openapi.yml#/components/schemas/FunctionRoutes'
  - scope: per-function
    surface: 'Fusebit Functions — task routes (v1)'
    name: maxRunning
    limit: 10
    unit: concurrently running tasks
    window: concurrent
    burst: null
    status_on_exhaustion: null
    configurable: true
    description: >-
      Caps concurrent task execution for the route. Exceeding it does not reject the request; it
      holds the task in the pending queue, which is what eventually trips maxPending. Default 10;
      specify 0 for unlimited concurrency.
    source: 'openapi/fusebit-http-api-core-openapi.yml#/components/schemas/FunctionRoutes'
undocumented_throttles:
  - surface: 'Module dependency build (v1)'
    operations: [putFunction, postFunctionBuild, getFunctionBuild]
    status: 429
    declared_description: Module dependency failed to build
    note: >-
      These three operations declare a 429 whose description ("Module dependency failed to build")
      does not describe a rate limit at all. Whatever the real throttle is on the npm build pipeline,
      its threshold, window and reset are unpublished. Recorded as an undocumented throttle rather
      than counted in limit_count, because no number was ever stated.
plan_limits:
  published: false
  note: >-
    No per-plan or per-account request quota was published. See plans/fusebit-plans-pricing.yml —
    Fusebit's pricing page is gone from DNS and no tier limits survive in any reachable document.
client_guidance: >-
  Historical. With no Retry-After and no budget headers, the only correct client behaviour against a
  Fusebit 429 was exponential backoff with jitter, plus keeping task submission rate below the
  route's own maxPending/maxRunning configuration.