Skip to main content
v1 is being retired on November 7, 2026 (end of the first week of November). Migrate to the v2 Vendor API at https://api.teamcaredental.com/api/v2/vendors. See the changelog for the migration guide.
The Vendor API limits how many locations a firm can be pulling data for at the same time. The unit is the request slot: every location-scoped request must carry a 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_key and 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 429 from the slot endpoint or a 401 from 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.
  • 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 401 on 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 the Retry-After header) on 429 and 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_key for the whole location pull; it lives for 6 hours.
  • SHOULD set items explicitly 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

A worker pool is the natural structure if you want parallelism: give each worker one location at a time and run at most 10 workers. The total number of locations you sync is unlimited.

Verifying your integration

Slots authorize. Request a slot for a location and call GET /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.