Tamara · Rate Limits
Tamara Rate Limits
Tamara does not publish a per-merchant request-per-minute/quota table in its public documentation. The merchant integration is structured around customer-driven checkout events and merchant-driven order operations (authorise/capture/cancel/refund), so most traffic is naturally bounded by retail volume.
Tamara Rate Limits is the machine-readable rate-limit profile for Tamara on the APIs.io network, conforming to the API Commons Rate Limits specification.
It captures 3 rate-limit definitions, measuring requests.
The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.
Tagged areas include Fintech, BNPL, Payments, Rate Limiting, and Throttling.
3 Limits
Throttle: 429
FintechBNPLPaymentsRate LimitingThrottling
Limits
Default Merchant API merchant
not publicly documented
Tamara's docs do not publish a numeric per-second/per-minute quota; traffic is bounded by retail purchase volume.
Sandbox merchant
sandbox shared environment
Sandbox at api-sandbox.tamara.co is shared infrastructure intended for integration testing, not load testing.
Channel Partner API channel_partner
not publicly documented
Numeric quotas for partner-api.tamara.co are negotiated as part of the channel partner agreement.
Policies
Idempotency
Re-issuing a `POST /orders/{order_id}/authorise` after a non-2xx response is unsafe — Tamara
instructs merchants to verify order status via Get Order Details before retrying, and to
not retry on Expired or Declined.
Webhook Retries
Tamara webhooks expect a 2xx response from the merchant endpoint quickly; non-2xx will be retried.
Backoff
Clients should implement exponential backoff with jitter on 429 and 5xx responses.