Documentation Index
Fetch the complete documentation index at: https://docs.veridianhp.com/llms.txt
Use this file to discover all available pages before exploring further.
Rate limits
Rate limits exist to protect both your practice and Veridian’s infrastructure from runaway clients. Normal practice traffic — even a busy practice — runs nowhere near these limits.Limits
Limits are per API key, evaluated as a token bucket.| Environment | Steady rate | Burst |
|---|---|---|
| Sandbox | 60 requests / minute | 120 requests |
| Production | 300 requests / minute | 600 requests |
Response headers
Every API response carries:Limit— the bucket sizeRemaining— tokens leftReset— unix timestamp at which the bucket refills fully
When you hit the limit
A429 response carries a Retry-After header in seconds:
Retry-After. Don’t busy-loop.
Patterns that stay well under the limit
- One session per invoice, not per render. Mint a session when the invoice is finalized, then reuse the URL until it expires.
- Webhook over polling. Use webhooks for state changes; reserve
/statusfor human-driven reconciliation. - Batch list calls. Pull a page of 100 with
limit=100rather than individual/statuslookups.
Patterns to avoid
- Polling
/statusevery second — wasteful and you’ll hit the limit. - One session per page load — your invoice will reach
succeededstate before you finish minting sessions. - Retrying instantly on 429 — exponential backoff with jitter, always.
What’s next
Errors
Full error code reference, including 429 details.
Webhooks
The pattern that eliminates polling entirely.
