429 response, so you will not be throttled for sending requests in quick succession.
What actually governs your throughput is different:
Your wallet
Every live check is charged. Your real ceiling is your balance: when it cannot cover the next check, that check is refused with
402, not throttled. Fund ahead of demand and set a low balance alert.Provider limits
Each scope is served by an upstream provider that may have its own limits. A provider that is slow or unavailable surfaces as a
failed check or a 502, not a rate limit response from Pruva.Practical guidance
- Do not build retry storms. Even without a rate limit, retrying failures in a tight loop wastes money, since each attempt is a real, billed check. Retry a
failedor502once, then reconcile. See Handling failed checks. - Batch sensibly. For large volumes, spread requests rather than firing them all at once, so a provider’s own limits do not turn into a wave of failures.
- Watch for change. Limits can be introduced as the platform grows. If a rate limit is added, it would return
429; handle that code gracefully now so you are ready, treating it as “slow down and retry after a short wait.”
This page describes current behavior. If your integration depends on a guaranteed throughput, talk to support about your volume rather than assuming the absence of a limit is a commitment.