Skip to main content
Rate limits apply per key, not per clinic, per workspace, or per IP address. There are two separate ceilings, and they’re easy to conflate:
  • A per-minute limit, enforced on every call, that refuses a call outright once it’s spent.
  • For an organization’s workspace plan, a per-month request allowance — see Usage and billing for how that one behaves (Essential is billed for going over, never blocked; only a contracted Enterprise hard cap can refuse a call for this reason).

​
Per-minute limits today

A clinic-owned key on the Team tier has no monthly request cap — only the 60-per-minute limit above. If you’ve seen a “100,000 requests a month” figure mentioned anywhere for a clinic’s own key, that was never enforced and doesn’t reflect a real limit; ask us if you’re unsure which limit actually applies to your integration.

​
Reading the headers

Every response — successful or not — carries headers telling you where you stand against the per-minute limit:
Watch RateLimit-Remaining and back off before it hits zero, rather than waiting to be told.

​
When you go over the per-minute limit

You get a 429 with code: "rate_limited" and a Retry-After header telling you how many seconds to wait:
Respect Retry-After exactly rather than retrying on a fixed interval — retrying too eagerly against a 429 just extends the wait for everyone using that key.
A 429 with code: "quota_exceeded" is a different limit — a contracted Enterprise workspace’s monthly allowance, not this per-minute bucket. See Errors and Usage and billing.

​
Designing around the limit

  • Cache what you can. Availability and catalogue data don’t need to be fetched on every page view of your own site — cache it and refresh on an interval, or in response to your own traffic patterns.
  • Use updated_since on list endpoints (see Pagination) so a periodic sync only pulls what changed, instead of the whole catalogue every time.
  • One key per integration, not one key shared across unrelated systems — each gets its own bucket, and a runaway process in one doesn’t starve another.