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: APIContext
providerId: apicontext
generated: '2026-09-04'
created: '2026-05-04'
modified: '2026-09-04'
method: searched
source: >-
  https://client.apimetrics.io/openapi.json (v2026-09-02), https://docs.apimetrics.io/llms.txt and its
  sitemap, and a live unauthenticated GET of https://client.apimetrics.io/api/2/calls/ on 2026-09-04.
limit_count: 0
description: >-
  APIContext publishes no API rate limits. This file previously carried a scaffold — X-RateLimit-*
  headers, a 10 req/min free tier and a 1,000 req/month quota — that the provider never published; it
  has been replaced with the measured finding.
headers: []
responseCodes: {}
limits: []
findings:
- what: response headers
  result: none
  evidence: >-
    No X-RateLimit-*, RateLimit-*, RateLimit-Policy or Retry-After header appears anywhere in the
    published OpenAPI, and a live unauthenticated request returned only content-type, vary,
    x-content-type-options, x-frame-options, strict-transport-security, x-cloud-trace-context, date,
    server, content-length, via and alt-svc.
- what: exhaustion status code
  result: none
  evidence: >-
    Not one of the 325 operations declares a 429 response. The declared 4xx set is 400, 403, 404, 409
    and 422.
- what: documented limits
  result: none
  evidence: >-
    No rate-limit, throttling or quota page appears in https://docs.apimetrics.io/sitemap.xml or in
    the llms.txt index.
- what: quota surface
  result: present-but-account-scoped
  evidence: >-
    The contract does expose consumption metering — GET /api/3/projects/billing/quota
    (project-quota), GET /api/3/projects/billing/usage-counts, GET /api/3/organizations/{org_id}/billing/quota,
    GET /api/2/account/quota — with QuotaLimits and QuotaCounts schemas. These report the account's
    MONITORING quota (how many synthetic calls the plan allows), not a request-rate limit on the REST
    API itself, and they require authentication. A 422 on run-call is documented in the provider's own
    Agent Skill as meaning "the project is out of quota", which is the only exhaustion signal the
    platform documents.
note: >-
  An honest zero. Limits may well exist server-side; the provider simply does not publish them and
  does not signal them in response headers, so an agent has no runtime way to back off.