Rate Limits

Limits

Rate limits are enforced per app using a sliding window counter. Every response includes rate limit headers so you can track your usage in real time.

Environment	Requests per minute
All environments	1,000

Requests that reach the practice’s EHR (live reads under /v4/ehr, re-syncs, document pulls, fax and prescription sends, eligibility checks, payer creation) also draw from your app’s share of the practice’s EHR login rate. Apps share one third of each EHR login’s rate; the rest is kept for the background syncs that keep the practice’s data current. For example:

EHR login	Login rate	App share
ModMed (EMA)	3 requests/second	1 request/second
EZDerm practice login	0.5 requests/second	1 request every 6 seconds
EZDerm personal login (with `X-Session-Token`)	3 requests/second	1 request/second

When the share is used up, live reads (/v4/ehr/* and the live schedule reads) answer 429 Too Many Requests with Retry-After. Other requests that reach the EHR fail with their usual EHR error (502/503 ehr_unavailable) instead, so a write whose outcome is unknown is never told to retry; retry those with backoff, and with the same idempotencyKey where the endpoint takes one. There are no daily caps: a loop is slowed to the share, not stopped for the day, so guard against loops in your app, especially for sends that act in the real world (faxes, prescriptions, paid eligibility checks). Sending a verified X-Session-Token makes EZDerm reads run on the signed-in user’s own login, at the personal rate.

Rate Limit Headers

Rate-limited API responses include these headers:

Header	Description
`X-RateLimit-Limit`	Maximum requests allowed per window
`X-RateLimit-Remaining`	Requests remaining in the current window
`X-RateLimit-Reset`	Unix timestamp when the window resets
`Retry-After`	Seconds until the window resets (only on 429 responses)

Handling Rate Limits

When you exceed the limit, the API returns 429 Too Many Requests:

{
  "code": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Maximum 1000 requests per 60 seconds.",
  "trace_id": "d4e5f6a7-b8c9-0123-defg-234567890123"
}

Recommended Approach

Use the X-RateLimit-Reset header to wait until the window resets before retrying. Fall back to exponential backoff with jitter if the header is missing:

async function fetchWithRetry(url, options, maxRetries = 3) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);

    if (response.status === 429) {
      const resetAt = response.headers.get("X-RateLimit-Reset");
      const waitMs = resetAt
        ? parseInt(resetAt) * 1000 - Date.now()
        : Math.pow(2, attempt) * 1000 + Math.random() * 1000;

      await new Promise((resolve) => setTimeout(resolve, Math.max(waitMs, 1000)));
      continue;
    }

    return response;
  }

  throw new Error("Max retries exceeded");
}

Best Practices

Batch requests where possible instead of making many individual calls
Cache responses for data that doesn’t change frequently (providers, facilities)
Use pagination with larger page sizes to reduce the number of requests
Monitor headers — check X-RateLimit-Remaining to throttle proactively before hitting the limit

Overview

Core Concepts

Working with Appointments

Working with Patients

Prescriptions

Patient Tracking

Building Apps

Limits

Rate Limit Headers

Handling Rate Limits

Recommended Approach

Best Practices

​Limits

​EHR rate share

​Rate Limit Headers

​Handling Rate Limits

​Recommended Approach

​Best Practices

Limits

EHR rate share

Rate Limit Headers

Handling Rate Limits

Recommended Approach

Best Practices