Rate limits

The API is rate limited per tenant, per API client and per calling address, so one busy integration cannot consume another's capacity.

When you are limited

HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": { "code": "rate_limit_error", "message": "Rate limit exceeded.", "correlationId": "corr_..." } }

Honour Retry-After. Back off exponentially with jitter rather than retrying on a fixed interval — a fleet retrying in lockstep re-creates the burst that caused the limit.

Carry your Idempotency-Key across retries so a retried mutation cannot duplicate. See Idempotency.

Designing within the limits

• Prefer webhooks to polling. Polling a verification every second is the most common cause of avoidable limiting.
• Where you must poll, back off as the wait lengthens.
• Cache what does not change often — credential configurations and issuer readiness change rarely.

Sandbox limits are generous enough to develop against. Specific limits depend on your plan; contact DiligenceID if an integration needs a higher ceiling.