Reference
Rate limit
Rate limits and the amount limits applied at creation. Verified accounts have no daily cap.
Going over the limit returns 429 with the code rate_limited. Wait a moment and try again.
| Endpoint | Limit | Scope |
|---|---|---|
All /v1/* | 300 requests / minute | per API key |
GET /v1/transactions/:id | 1 request / second | per transaction, per API key |
| Public checkout page | 120 requests / minute | per IP |
The headers differ per limit. GET /v1/transactions/:id answers carry RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset, and its 429 adds Retry-After in seconds. The 300 requests / minute limit answers 429 rate_limited with none of these headers, so do not wait for a Retry-After that never comes: back off with exponential delays and leave room in the budget for creating payments.
Don't poll a transaction for its status — the payment.paid webhook tells you the moment it is paid, and a finished transaction is served from cache. Why the per-transaction limit exists and how to live with it: one status read per second per transaction. Handling bursts in general: rate limits and request spikes.
Amount limits
Applied at creation. Values may differ per account; the defaults are below. There is no cap on the number of requests or the total amount per day.
| Limit | Default | Rejected with |
|---|---|---|
| Minimum amount | QRIS Rp1,000 · VA Rp10,000 | 422 amount_too_small |
| Maximum amount | Rp10,000,000 | 422 amount_too_large |
| Expiry | 60 minutes (max 24 hours) | 422 expiry_too_long |
A VA maximum can be raised for your account: email halo@fintar.id.
Before onboarding is active
An account whose onboarding is not yet active gets an additional lifetime allowance. It never resets: the only thing that lifts it is completing verification. Payments already received are unaffected, and nothing is lost when the tier is reached — new payment requests are refused until verification is done.
| Limit | Default | Counts | Rejected with |
|---|---|---|---|
| Requests, lifetime | 10 | Every request ever created except canceled ones. Expired and failed requests still count. | 429 unverified_count_cap |
| Total amount, lifetime | Rp1.000.000 | Only money received or still receivable: pending and succeeded. An expired, failed or canceled request releases its share again. | 429 unverified_amount_cap |
Test-mode requests never consume either allowance and are never refused by it. Unlike rate_limited, waiting does nothing here, so retry logic should stop rather than back off.