Toss Payments · Rate Limits

Toss Payments Rate Limits

Toss Payments does not publish fixed numeric per-account or per-endpoint rate limits for the Core API. Practical throughput is governed by the nature of the operation rather than a documented per-minute request cap: billing-key authorization can take up to 60 seconds to complete, transaction queries return up to 5000 records per page (cursor pagination via startingAfter), cash receipt queries up to 10000 records, and payout requests accept up to 100 payouts per call (max 1 billion KRW). Clients should implement idempotency (via Idempotency-Key on mutating calls where supported), exponential backoff, and webhook-based reconciliation rather than tight polling.

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

It captures 5 rate-limit definitions, measuring requests, records, payouts, and seconds.

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

Tagged areas include Payments, Payment Gateway, South Korea, Rate Limiting, and Quotas.

5 Limits Throttle: 429
PaymentsPayment GatewaySouth KoreaRate LimitingQuotas

Limits

Core API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the Core API.
Transactions Query Page Size account
records
5000 per page
The /v1/transactions endpoint returns up to 5000 records per page with cursor pagination (startingAfter).
Cash Receipts Query Page Size account
records
10000 per page
The /v1/cash-receipts query returns up to 10000 records per page.
Payout Batch Size account
payouts
100 per request
The v2 payouts endpoint accepts up to 100 payout requests per call (max 1 billion KRW total).
Billing Authorization Time request
seconds
up to 60s
Charging a billing key / authorization can take up to 60 seconds to complete.

Policies

Idempotency
Mutating operations such as cancellation support an Idempotency-Key header so retries do not double-apply.
Webhook Retries
Undelivered webhooks are retried up to seven times with exponentially increasing intervals (from 1 minute up to 4096 minutes); endpoints must return HTTP 200.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses, and reconcile via webhooks rather than tight polling.

Sources