Openpay · Rate Limits

Openpay Rate Limits

Openpay does not publish explicit numeric request-per-second or request-per-minute rate limits in its public API reference. As a payments platform it applies account- and merchant-level throttling and anti-fraud controls, and may return HTTP 429 or service-unavailable responses under excessive load. List endpoints are paginated via offset and limit query parameters. Specific per-merchant limits are not reconciled in this artifact and should be confirmed with Openpay.

Openpay Rate Limits is the machine-readable rate-limit profile for Openpay on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests, records, and transactions.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Payments, Fintech, Cards, SPEI, and Subscriptions.

3 Limits Throttle: 429
PaymentsFintechCardsSPEISubscriptionsRate LimitingQuotasThrottling

Limits

Requests Per Merchant merchant
requests
see provider documentation
No public numeric per-merchant request rate limit is documented.
List Pagination endpoint
records
offset / limit query parameters
List endpoints return paginated results; default limit is small (commonly 10).
Anti-Fraud Throttling account
transactions
dynamic
Velocity and anti-fraud rules may decline or throttle bursts of card charges.

Policies

Pagination
Use offset and limit on list endpoints to page through charges, customers, payouts, and fees.
Backoff Strategy
Clients should implement exponential backoff with jitter on 429 and 5xx responses and avoid retrying non-idempotent charge creation without an order_id.
Idempotency
Send a unique order_id on charges and payouts to avoid duplicate transactions on retry.

Sources