Mono · Rate Limits

Mono Africa Rate Limits

Mono does not publish a single fixed numeric rate-limit table for its public APIs. In practice, throughput is governed by your application's tier and agreement, and some data endpoints are constrained by upstream bank/institution availability rather than by a Mono per-minute cap. Real-time data reads (for example transactions with the `x-real-time` header) are slower and more tightly bounded than cached reads because they hit the institution directly. Clients should handle HTTP 429 responses with exponential backoff.

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

It captures 3 rate-limit definitions, measuring requests and transactions.

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

Tagged areas include Open Banking, Financial Data, Payments, Rate Limiting, and Quotas.

3 Limits Throttle: 429
Open BankingFinancial DataPaymentsRate LimitingQuotas

Limits

API Requests application
requests
not published
No fixed numeric request-rate limit is documented; governed by tier/agreement.
Real-Time Data Reads account
requests
institution-bound
Real-time reads (x-real-time header) are bounded by upstream bank availability and latency.
DirectPay Collections application
transactions
not published
Payment throughput governed by account/agreement and bank rails, not a documented cap.

Policies

Backoff Strategy
Implement exponential backoff with jitter on HTTP 429 and honor any Retry-After header.
Data Status Gate
Check the account `data_status` field before calling financial-data endpoints; data may still be syncing.
Webhooks Over Polling
Prefer webhook events (account updates, payment status) over tight polling loops to reduce request volume.

Sources