Skip to main content
Check the HTTP status and response body. Successful responses use ok: true and place the result in data. Errors use this shape:
Use error.code to handle failures in your application and error.message to explain them. details and requestId are optional.

Choose the next action by failure type

Retry a request

For RATE_LIMITED, wait for Retry-After when supplied. Otherwise, wait progressively longer between retries and limit the number of attempts. For SCROLL_BUDGET_EXCEEDED or REPORTS_QUERY_TOO_EXPENSIVE, shorten the date range or filter to a campaign before starting a new query. A BAD_CURSOR needs a new event query without the old cursor. After a timeout during a write, check whether the change was saved before repeating the request. This avoids creating duplicate entities.

Get help

Include the method, endpoint, status, error code, and request ID when available. For report issues, include the date range and timezone. Leave API keys and Authorization headers out of logs and support messages.