request_key obtained from POST /locations/{location_id}/slots in the X-Vendor-Request-Key header, and only a fixed number of those keys are active per firm.
Limits
The token endpoint,
GET /organizations and GET /locations do not need a slot and are not counted.
Need more than 10 concurrent locations? Contact TeamCare support and we will raise your firm’s quota.
How slots behave
- One slot per location. Requesting a slot for a location you already hold refreshes it with a new
request_keyand resets its 6-hour validity (subject to the 2-minute cooldown). The previous key for that location stops working. - The 10 newest win. Your active slots are the 10 most recently requested. When you request an 11th, the oldest key is trimmed immediately, even if a sync is still running on it, and its requests fail with
401 {"errors": "Invalid, expired or missing request key"}. - Any number of requests per slot. There is no cap on how many requests you send against one
request_key, or how fast you page through a location. - Rejected requests cost nothing. A
429from the slot endpoint or a401from a trimmed key executes nothing, so retrying is safe.
Throttled slot request
Rate-limited requests (more than 10 slot requests in 10 seconds) return
429 with a Retry-After header and no body fields.
Recommended client behavior
- SHOULD request a slot, pull all of that location’s data, then move to the next location. One slot per location per sync run is the intended pattern.
- MUST keep parallel locations at or below your quota (10 by default). An 11th slot silently kills the oldest sync.
- MUST treat
401on a data request as “request a fresh slot”, not as an authentication failure, when the access token is still valid. - MUST honour
retry_after(or theRetry-Afterheader) on429and never retry in a tight loop. - MUST cache the access token and reuse it for its 6-hour lifetime.
- SHOULD NOT re-request a slot per data call. Keep the
request_keyfor the whole location pull; it lives for 6 hours. - SHOULD set
itemsexplicitly when paging. Cursor pagination defaults to 10 records per page and accepts up to 5000. - SHOULD use
q[fetch_modified_since]for routine polling so each run touches only changed records.
Reference implementation
Verifying your integration
Slots authorize. Request a slot for a location and callGET /patients with the X-Vendor-Request-Key header. The call succeeds. The same call without the header returns 401.
The cooldown triggers. Request the same location’s slot twice within 2 minutes. The second call returns 429 with retry_after.
The quota trims. Request slots for 11 distinct locations. A data request with the first location’s request_key now returns 401; the other 10 still work.
Normal operation is clean. Run your usual sync, one slot per location, with fan-out capped at 10, and confirm you see no 429 or 401 responses.
