generated: '2026-08-26'
method: searched
source: >-
  openapi/pay-i-openapi-original.json (all 63 operations),
  https://docs.pay-i.com/docs/list-of-all-supported-headers,
  https://docs.pay-i.com/docs/handling-errors, https://docs.pay-i.com/docs/limit-states
limit_count: 0
rate_limits: []
response_headers: []
exhaustion_status: null
evidence:
- source: openapi/pay-i-openapi-original.json
  detail: >-
    No 429 response is declared on any of the 63 operations. Declared error statuses are
    400, 401, 403, 404 and 424 only.
- url: https://docs.pay-i.com/docs/list-of-all-supported-headers
  status: 200
  detail: >-
    The complete header cheat sheet lists 15 xProxy-* headers and contains no X-RateLimit-*,
    RateLimit-* or Retry-After header.
- url: https://docs.pay-i.com/docs/handling-errors
  status: 200
  detail: No 429, rate limit, throttle or Retry-After language present.
note: >-
  Pay-i documents no HTTP rate limits and returns no rate-limit response headers. An agent calling
  this API has no runtime signal telling it how much budget it has left in request terms. This is
  an honest zero.
x-adjacent-control: >-
  Pay-i's throttling concept is economic rather than request-rate based, and it IS well documented
  — spend Limits with a risk threshold, a per-limit `state` (ok / exceeded) returned in the
  xproxy_result object on every proxied response, and HTTP 424 Failed Dependency when a blocking
  limit stops the upstream provider call. That is a real runtime cost signal, but it is a spend
  control, not a rate limit, and it is recorded in conventions/pay-i-conventions.yml under
  spend_limits rather than counted here.