Skip to main content
PIK applies rate limits to all API endpoints to ensure fair usage and platform stability. If your integration exceeds the allowed request rate, PIK returns a 429 Too Many Requests response. This page explains how rate limiting works and how to handle it correctly.

How rate limiting works

PIK enforces rate limits per API key. Limits are applied on a rolling window basis — PIK counts the number of requests made within a sliding time window and rejects requests that exceed the limit for that window. Rate limits apply independently per endpoint group. For example, the payment creation endpoints have separate limits from the FX conversion endpoints. Hitting the limit on one group does not affect your ability to call other endpoint groups.

Default limits

The default rate limits for PIK API keys are: General endpoints — 300 requests per minute per API key. Payment creation — 60 requests per minute per API key. FX conversion — 60 requests per minute per API key. Payout creation — 30 requests per minute per API key. Webhook registration — 10 requests per minute per API key. If your platform requires higher limits for production use cases, contact your PIK account manager to discuss increased rate limits for your account.

Handling 429 responses

When you receive a 429 response, check the Retry-After header in the response. This header contains the number of seconds to wait before retrying the request. Do not retry before this interval — retrying immediately will result in further 429 responses and does not reset the window. Implement exponential backoff with jitter in your integration for all retry logic. A simple approach is to wait for the Retry-After interval, then retry once. If the retry also returns a 429, double the wait time before the next retry, up to a maximum of 60 seconds.

Best practices

Avoid polling — Do not poll status endpoints at high frequency. Use webhooks to receive real-time notifications instead of repeatedly calling GET endpoints to check payment or payout status. Batch where possible — If you need to create multiple payment links or retrieve multiple account balances, spread the requests out rather than firing them all simultaneously. Use idempotency keys — For payment and payout creation, include an Idempotency-Key header with a unique value per request. If your request times out and you retry, PIK will return the original response rather than creating a duplicate transaction. Monitor your usage — Track the X-RateLimit-Remaining header returned on each response to monitor how close you are to your limit before hitting it.