max_attempts_reached — chunk attempts exhausted

The chunk came back in skipped[] of the 202 response to POST /orders/{order}/items/retry-failed with reason: "max_attempts_reached" and a human-readable reason_label. The bulk retry completed successfully — just without this chunk.

The attempt limit is 5 per chunk, and it has been used up. There will be no sixth retry, neither bulk nor single-chunk: POST /orders/{order}/items/{item}/retry on such a chunk returns 400.

Build your logic on reason, not on reason_label: the label comes in the language of the key and can change. Trap: the can_retry flag in OrderItem looks ONLY at the chunk status and knows nothing about the number of attempts — can_retry: true with exhausted attempts is perfectly normal. This chunk can no longer be salvaged; what remains is a separate order for its text. Neighboring codes in the same skipped[]: superseded (the chunk already has a successful version — it is healthy, nothing needs to be done), active_retry_exists (a retry is already running — wait for it), policy_flagged (corrected text is required), insufficient_funds (no locked remainder price_units − consumed_units is left).

GET /orders/{order}/items/{item}/text → POST /orders with that text as a new order. It is paid: the locked remainder of the original order does not carry over to it.

• policy_flagged — neighboring code in skipped[]
• Guide: retries and idempotency
• POST /orders/{order}/items/retry-failed
• GET /orders/{order}/items/{item}/text
• POST /orders