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: Densify
providerId: densify
generated: '2026-09-06'
created: '2026-05-04'
modified: '2026-09-06'
method: searched
source: >-
  openapi/ (21 first-party Kubex specs) and a documentation search of docs.kubex.ai for
  rate limiting / throttling / requests per minute
docs: null
limit_count: 0
note: >-
  Kubex publishes NO numeric rate limits. This file previously carried a 2026-05-04 bulk-sweep
  scaffold asserting 10/100/1000 requests-per-minute tiers and a full X-RateLimit-* header set;
  none of that was ever published by the provider and all of it has been removed. What IS
  contractually declared is a single 429 on the credential exchange.
headers:
  limit: null
  remaining: null
  reset: null
  retryAfter: null
  policy: null
  note: >-
    No X-RateLimit-*, RateLimit-* or Retry-After header appears in any of the 21 specs or in the
    documentation. An agent gets no runtime budget signal from this API — it learns it is
    throttled only by receiving a 429.
responseCodes:
  throttled: 429
  quotaExceeded: null
  serviceUnavailable: 500
limits:
- scope: per-credential
  operation: authorize-user
  path: POST /authorize
  window: unspecified
  limit: null
  burst: null
  behavior: progressive delay
  status: 429
  description: >-
    "Too Many Requests (rate limiting / progressive delay)" — declared on the authorization
    endpoint only. The delay lengthens with repeated failures, so a retry loop on a bad
    credential gets slower rather than being hard-blocked.
  evidence: openapi/densify-authorize-openapi.yaml
plan_limits:
  note: >-
    Plans are priced per vCPU and per GPU of managed infrastructure, not per API call, and
    neither published plan carries an API quota. See plans/densify-plans-pricing.yml.
checked: '2026-09-06'