Rate limits & SLAs
Rate limits
Section titled “Rate limits”At launch, RandaVerify does not enforce a hard request-rate cap on Self-Hosted integrators. The practical limits are:
- Concurrent connections per token: 32. Beyond this, additional requests are queued at the load balancer.
- NIMC upstream throughput is the actual bottleneck. Burst traffic above ~5 requests/sec/org is likely to see queueing latency.
- We reserve the right to introduce a
429 Too Many Requestsresponse if any single org’s volume jeopardises platform stability. You will be notified by email at least 7 days before enforcement begins.
If your use case requires guaranteed throughput beyond the above, contact support for a discussion.
Latency expectations
Section titled “Latency expectations”| Endpoint | p50 | p95 |
|---|---|---|
/login | 200 ms | 600 ms |
/verify-nin | 1.2 s | 4 s |
/verify-nin/in-person | 2.5 s | 6 s |
/verify-nin/share-code | 1.4 s | 4.5 s |
/verify-nin/phone | 1.4 s | 4.5 s |
/verify-nin/demography | 1.4 s | 4.5 s |
/verify-nin/requery (local hit) | 80 ms | 250 ms |
/verify-nin/requery (NIMC fallback) | 1.2 s | 4 s |
These are measured at the RandaVerify edge — your actual experience will include your own network’s RTT.
Set a 45-second client timeout on verification calls to be safe.
Availability
Section titled “Availability”Target: 99.5% monthly uptime at launch. Planned maintenance windows are communicated by email at least 48 hours in advance and scheduled outside of Nigerian business hours where possible.
NIMC upstream outages are outside our control and are passed through as 5xx responses. We do not deduct units for requests that failed due to NIMC unavailability.
Status page
Section titled “Status page”A public status page is on the roadmap. Until it ships, support will email all customers within 30 minutes of any incident affecting verification availability.