Increase · Rate Limits

Increase Com Rate Limits

Increase applies per-API-key rate limits to protect the platform, and returns HTTP 429 (Too Many Requests) when a key exceeds its allowance. Increase does not publish a single fixed public number for the request-rate ceiling; the effective limit is set per environment and per customer, and can be raised for production workloads by contacting Increase. The API is designed to be called safely at scale: every mutating request accepts an `Idempotency-Key` header so retries after a 429 or network error do not create duplicate transfers, and all list endpoints use cursor-based pagination (limit 1-100 per page, default 100) rather than offset paging. Webhook delivery has its own operational limits: Increase expects a 2xx response within 10 seconds and retries up to 8 times over roughly 72 hours before giving up, after which the List Events API (30-day retention) is the recovery path.

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

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

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

Tagged areas include Payments, Banking, ACH, Rate Limiting, and Quotas.

5 Limits Throttle: 429
PaymentsBankingACHRate LimitingQuotas

Limits

API Requests api_key
requests
not published (per-key, tunable)
Increase rate-limits per API key and returns 429 when exceeded; production limits can be raised on request.
List Page Size request
records
100
Cursor-paginated list endpoints return 1-100 items per page (default 100).
Webhook Response Window endpoint
seconds
10
Your endpoint must return a 2xx status within 10 seconds or the delivery counts as failed.
Webhook Retry Attempts event
attempts
8
Failed webhook deliveries are retried up to 8 times over ~72 hours, then abandoned.
Events Retention account
days
30
The List Events API retains events for 30 days for polling / backfill after missed webhooks.

Policies

Idempotency
Mutating requests accept an Idempotency-Key header so retries after a 429 or error are safe and never duplicate money movement.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor 429 responses rather than retrying tightly.
Cursor Pagination
List endpoints use opaque cursors instead of offsets, keeping large sweeps stable and bounded per page.
Webhook Plus Polling
Because webhooks have a bounded ~72-hour retry window, Increase recommends combining Event Subscriptions with periodic List Events polling for durable synchronization.

Sources