Bunq · Rate Limits

Bunq Rate Limits

Bunq applies HTTP-method-specific rate limits per IP address per endpoint across both sandbox and production. Limits are not differentiated by paid plan; they apply uniformly to all callers and are intended to protect the platform rather than bound a paid quota. The /session-server endpoint has a much stricter ceiling than other endpoints. When the threshold is exceeded the API returns HTTP 429.

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

It captures 5 rate-limit definitions, measuring requests_per_3_seconds, requests_per_30_seconds, and callback_urls_per_category.

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

Tagged areas include Banking, Fintech, Rate Limiting, and Throttling.

5 Limits Throttle: 429 Quota: 429
BankingFintechRate LimitingThrottling

Limits

GET requests (general) IP/endpoint
requests_per_3_seconds · second
3
3 GET requests per 3 seconds per IP per endpoint.
POST requests (general) IP/endpoint
requests_per_3_seconds · second
5
5 POST requests per 3 seconds per IP per endpoint.
PUT requests (general) IP/endpoint
requests_per_3_seconds · second
2
2 PUT requests per 3 seconds per IP per endpoint.
/session-server endpoint IP/endpoint
requests_per_30_seconds · second
1
Stricter limit on session creation. 1 request every 30 seconds per IP.
Callback URL configuration account
callback_urls_per_category
2
Maximum 2 callback URLs may be configured per notification category.

Policies

Per-IP / Per-Endpoint Scoping
Rate limits are applied per IP address per endpoint, so each unique IP has independent quotas against each endpoint.
Method-Specific Thresholds
GET, POST and PUT each have their own per-3-second threshold; mixing methods does not consume a shared quota.
429 on Excess
Exceeding any threshold returns HTTP 429 RATE LIMIT. Clients should pause and retry on the affected endpoint.
Session Endpoint Hardening
The /session-server endpoint enforces a much stricter (1 per 30 seconds) ceiling. Reuse sessions rather than re-authenticating per call.
Backoff Strategy
Use exponential backoff with jitter when 429 is observed. bunq does not document a Retry-After header so backoff intervals must be client-managed.

Sources