Getamber Dev Rate Limits
Ambr documents rate limiting in one paragraph of its developers page ("Errors & rate limits"): "Several write endpoints are rate-limited, per IP or per API key (revocation allows 5 requests per minute per IP). Back off and retry after retry_after_ms on 429." The only numeric limit published is the revoke endpoint's; the other write limits are stated to exist but not quantified. The 429 body carries the error code rate_limited and a retry_after_ms field — the retry signal is IN THE BODY, not a Retry-After or RateLimit-* header. The 0.2.0 changelog entry (2026-04-10) lists "rate limiter" under security hardening. Probed 2026-09-19: twelve consecutive anonymous GETs to /api/v1/pricing all returned 200 with no RateLimit-*, X-RateLimit-* or Retry-After headers, so read endpoints expose no per-request quota signal. limit_count reflects the one quantified limit; the unquantified write limits are recorded below with limit null rather than invented.
Getamber Dev Rate Limits is the machine-readable rate-limit profile for Ambr on the APIs.io network, in the API Commons Rate Limits shape.
It captures 2 rate-limit definitions, measuring requests_per_minute and requests.
Limit state is signalled in the rateLimit, rateLimitRemaining, rateLimitReset, and retryAfter response headers, and an exhausted limit returns HTTP 429.
The profile also includes response codes documented for throttled, errorCode, and bodyField.
Tagged areas include Company, AI Agents, Agentic Commerce, Contracts, and Legal.
rateLimitrateLimitRemainingrateLimitResetretryAfter
Limits
Sources
Work with this as data
Every rate limit here is available over the APIs.io API and to AI agents over MCP.