Rate limits
What is enforced today
Public v1 route handlers do not currently emit rate-limit headers (X-RateLimit-*, Retry-After) and do not implement a dedicated per-key throttle in those handlers.
That means:
- You should still design clients for reasonable volume (batch with pagination, cache where appropriate).
- Platform-level abuse protection (edge / infrastructure) may still reject pathological traffic.
- Do not assume unlimited parallel polling is supported.
Plan catalog (reference only)
lib/pricing/plan-core.ts includes an apiRateLimit field that maps to apiRateLimitRpm (requests per minute) in the plan registry:
Treat these as product catalog limits, not a guarantee that public v1 already returns
429 when exceeded. When enforcement ships in the public handlers, this page and OpenAPI will be updated.
Recommended client behavior
- Prefer incremental sync (filter appointments by
startDate/endDate) over full-table pulls every minute. - Cap concurrency (for example 1–2 parallel requests per key).
- On unexpected
5xxor connection errors, use exponential backoff with jitter. - Cache customer lists when your job only needs appointments.
If you need higher volume
Contact sales / support for Enterprise. Do not scrape dashboard HTML or call session-authenticated/api/* routes from an integration — those are not the public contract.