Stay under their rate limits

How to do it

Write the provider's limits in the adapter's settings, with a link to where they are published. Count calls in one place that every worker shares, such as Redis, so ten workers do not each use the full limit. Read Retry-After in both forms, a number of seconds or an HTTP date. Read the provider's rate limit headers too, as tell clients their rate limit describes them. Slow down before the remaining count reaches zero. Bulk jobs, such as nightly syncs, use a smaller share of the limit than calls a person waits for.

Examples

JavaScript example

function retryAfterMs(header, now = Date.now()) {
  if (header == null) return 0;
  const seconds = Number(header);
  if (Number.isInteger(seconds) && seconds >= 0) return seconds * 1000;
  const date = Date.parse(header);
  return Number.isNaN(date) ? 0 : Math.max(0, date - now);
}

Python example

from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

def retry_after_seconds(header: str | None, now: datetime | None = None) -> float:
    if header is None:
        return 0
    if header.isdigit():
        return int(header)
    try:
        moment = parsedate_to_datetime(header)
    except (TypeError, ValueError):
        return 0
    return max(0, (moment - (now or datetime.now(timezone.utc))).total_seconds())

How to check

Make the provider's fake answer 429 with Retry-After: 120 once. No worker calls the fake again within 120 seconds. A load test at twice the normal job size gets no 429 from the fake.

Sources

• RFC 9110 section 10.2.3 Retry-After

Related rules

• Tell clients their rate limit in API design