Blame
|
1 | # Rate Limits |
||||||
| 2 | ||||||||
|
3 | Rate limits protect AeThex services from overload and abuse. |
||||||
|
4 | |||||||
|
5 | --- |
||||||
|
6 | |||||||
|
7 | ## Best Practices |
||||||
| 8 | ||||||||
| 9 | - Cache non-sensitive responses. |
|||||||
| 10 | - Retry with exponential backoff. |
|||||||
| 11 | - Avoid tight polling loops. |
|||||||
| 12 | - Prefer webhooks for async events. |
|||||||
| 13 | - Treat 429 responses as a signal to slow down. |
|||||||
| 14 | ||||||||
| 15 | --- |
|||||||
| 16 | ||||||||
| 17 | ## Suggested Client Behavior |
|||||||
| 18 | ||||||||
| 19 | When rate limited: |
|||||||
| 20 | ||||||||
| 21 | 1. Stop the immediate retry loop. |
|||||||
| 22 | 2. Read retry headers if provided. |
|||||||
| 23 | 3. Back off. |
|||||||
| 24 | 4. Queue non-urgent work. |
|||||||
| 25 | 5. Surface a helpful message to users. |
|||||||