Handle API errors and background work

Read the complete failure

1. Record the HTTP status.
2. Read the stable error.code.
3. Read safe values in error.details.
4. Keep the returned x-request-id.
5. Apply the operation's documented correction.

Know when not to retry

Validation, authentication, permission, licence, missing resource, and state conflict failures normally need a change before retry. Do not repeat a POST after an uncertain outcome until you have read the current resource or background operation state.

Use bounded retry for temporary failure

For an explicitly retryable dependency or capacity failure, use bounded exponential backoff and any documented Retry-After value. Stop after the approved limit and retain the request IDs.

Monitor background work

Keep the job, run, import, build, or activation identifier returned by the action. Poll the documented status operation or use its event stream. Treat waiting and terminal states differently.

Raise a support case safely

Provide the Product version, time, operation ID, status, stable error code, request ID, tenant identifier when safe, and background identifier. Do not attach credentials or customer content unless the approved support process requires it.

Reference

Each operation page lists causes, corrections, retryability, and partial work guidance. Shared error fields are in the Common HTTP models.

Registration is a separate gate

When the 720 powered on hour allowance is exhausted, ordinary API work and exports are denied. Repeated retries do not restore access. A System Owner must complete registration or renewal.