Work within rate limits
MyCRM uses a token-bucket rate limiter with different costs for different requests. A remaining balance is a number of tokens, not necessarily a number of requests.
Read the response headers
| Header | How to use it |
|---|---|
X-RateLimit-Cost | Cost of the current request |
X-RateLimit-Limit | Applicable token allowance |
X-RateLimit-Remaining | Remaining token balance when provided |
Retry-After | Delay guidance when provided; a costly request may need more time |
X-RateLimit-Reset | Reset metadata when provided by the limiter |
Header availability depends on the limiter's response metadata. Do not require every header on every response. The samples describe allowances over five minutes; the period and limits are configurable, so avoid hard-coding a universal allowance.
Why one request costs more than another
The resource and operation establish the base cost. Collection searches are generally more expensive than reading one known record. Numbered-page depth, sorting by fields other than ID, and included relationships can further increase cost. Deeper includes compound the work needed.
The reviewed default peak window is 08:00–18:00 Brisbane time (AEST, UTC+10). Per-application limits and operational configuration can vary, and LMG can adjust them to protect the service. Schedule bulk work outside peak periods where practical, while continuing to respect actual response headers.
Handle 429 Too Many Requests
Pause new work for the affected application, honour Retry-After when supplied, and use bounded backoff with jitter. Reduce concurrency and query cost if throttling continues. Do not spin in a tight retry loop.
A lower-cost design often starts from the resource nearest the desired data, uses a relationship endpoint when only IDs are needed, and selects a small fieldset. For large traversals, ID-based batching can avoid deep numbered pages where supported.
Rate limiting does not make uncertain writes safe to retry. Keep retry policy separate from write reconciliation.