HTTP errors and retries
Decide whether an API request needs correction or a delayed retry.
On this page
What you need
The failed request's HTTP status and response, without exposing its key or token.
How to do it
- Read status, code, detail and request_id. X-Request-ID also identifies the request.
- For 429 or a temporary 503, wait for Retry-After and retry the same prepared data with the same IDs.
- Correct access, size, conflicts or invalid data before retrying permanent errors.
Good to know
401 means missing or invalid sign-in or key; 403 means access is not allowed. 409 indicates a conflict. 413 means the request is too large; 422 means data is invalid. 429 means a rate or usage limit was reached.
Problem responses use application/problem+json. Use the stable code in automation; the readable detail can change with language. Never retry every 5xx blindly: check whether a write may already have succeeded.
If something goes wrong
For help, provide the request ID, error code and time. Remove authentication headers, personal payloads and secrets from any shared example.
Related guides
- Send your own monitoring data
Send your own readings over HTTPS using the IDs and keys of your monitor.
- Diagnostic checklist
Find where readings or notifications stop before changing multiple settings.
- Quotas and fair use
Plan your monitoring within the shared limits of your account.