Rate limits and response headers

Per-token request limits

Each private integration has a requests-per-minute limit selected when the credential is created. The counter belongs to that key, which lets separate integrations have different traffic policies and prevents one client from silently consuming another client allocation.

Choose a limit that supports normal work with room for short bursts. A higher number is not a substitute for batching, caching stable metadata, filtering searches, limiting results, or avoiding duplicate calls.

Response headers

Retry strategy

1. Set a finite connection and response timeout.
2. Retry only temporary network failures, selected 5xx responses, and 429 responses.
3. Honor Retry-After and add bounded jitter to prevent synchronized retries.
4. Set a small maximum attempt count and a total time budget.
5. Do not retry invalid credentials, insufficient scopes, invalid arguments, unavailable operations, or approval-required responses.
6. Use idempotency protections before retrying any future supported mutation workflow.
7. Alert the integration owner when failures persist beyond the retry budget.

Reduce unnecessary traffic

• Use the operation query and limit parameters instead of downloading every contract repeatedly.
• Cache public operation display metadata briefly but refresh after scope, service, token, or registry changes.
• Request only the records and time range required for the integration purpose.
• Debounce interactive searches and cancel requests that are no longer needed.
• Separate background synchronization from user-facing traffic with different credentials and limits.
• Avoid health checks more frequent than the operational need.

Control concurrency with a work queue

A worker queue should cap concurrent Lead360 requests for each token and stop optional jobs as X-RateLimit-Remaining approaches zero. Prioritize interactive customer support reads over background refresh work, and spread recurring jobs across the minute instead of starting every synchronization at the same second.

When several processes share one token, use a shared limiter so each process sees the same remaining budget. A safer design gives independent workloads separate least-privilege credentials and limits, making ownership, alerts, rotation, and traffic investigation easier. Do not create extra keys merely to bypass a reasonable platform limit.

Measure request volume by operation key, response status, and latency without recording full customer responses. Use those measurements to remove duplicate reads, improve filters, and set the next credential limit based on observed production demand.