Skip to main content

​
Rate limits

​
What is enforced today

Public v1 list routes enforce a sliding-window throttle per organization API key and caller IP. Default public v1 budget: Successful responses include:
  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • X-RateLimit-Reset (Unix seconds)
List routes also enforce limit <= 100, support offset, and use stable descending ordering so offset pagination does not reshuffle rows with identical timestamps. When the window is exhausted, the API returns 429 with Retry-After plus the same rate-limit headers.

​
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 plan catalog ceilings. The live public v1 handler budget may be lower for abuse protection and can be raised for Enterprise integrations by agreement.
  1. Prefer incremental sync (filter appointments by startDate / endDate) over full-table pulls every minute.
  2. Cap concurrency (for example 1–2 parallel requests per key).
  3. On 429, wait at least Retry-After seconds before retrying.
  4. On unexpected 5xx or connection errors, use exponential backoff with jitter.
  5. Cache customer lists when your job only needs appointments.
Write endpoints are not available in Public API v1. See Public API write surface.

​
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.