{"slug": "claude-message-batches-what-to-do-with-each-result-state", "title": "Claude Message Batches: What to Do With Each Result State", "summary": "A developer outlined a pattern for handling Claude's Message Batches API results, stressing that each request needs a custom_id from the caller's own records and that the four result states — succeeded, errored, canceled and expired — each require different follow-up. The writeup warns that succeeded only means a message exists, not that it is correct, and that resubmitting a whole batch after partial failures risks duplicate tasks or overwriting human decisions, so execution should be separated from model output via an approved_for_action gate.", "body_md": "The Message Batches API processes independent Messages API requests asynchronously. Submitting a batch is easy. The design work is in what happens after the results come back, especially when some succeed and some do not.\n\nUse a batch for independent work that can wait: evaluations, document classification, data analysis. Use an interactive request when a person or service needs the answer before it can continue. A batch can take up to 24 hours, so check the current limits in the documentation before building anything time sensitive.\n\nResults can come back in a different order from the requests you sent. Give each request a `custom_id` taken from your own record, such as `ticket_8831`, and store the mapping before you submit. When results arrive, write each outcome next to its source record, with the prompt version, submission time and status.\n\n| State | What it means | Next step | \n|---|---|---|\n| `succeeded` | The model returned a message | Validate the message and its business meaning before any action | \n| `errored` | The request failed | Read the error. Fix invalid input; retry only errors that are eligible | \n| `canceled` | The batch was canceled | Check each request. A canceled batch can still contain completed results | \n| `expired` | The request was not sent before the batch expired | Decide which requests are still useful, then resubmit those | \n\n`succeeded` is the state people misread. It means a message exists, not that the message is right for the decision.\n\nWhen a few records fail, the tempting fix is to resubmit everything. That can create duplicate tasks or overwrite decisions a person already made. Instead:\n\nFor refunds, notices, account changes or payments, separate the model's output from execution:\n\n`approved_for_action` only after validation and any required review.\n`custom_id` joins a result to its input. It does not make execution idempotent. That job belongs to the service that performs the action.\n\n`custom_id` values.", "url": "https://wpnews.pro/news/claude-message-batches-what-to-do-with-each-result-state", "canonical_source": "https://dev.to/poorna_reddy/claude-message-batches-what-to-do-with-each-result-state-ll2", "published_at": "2026-10-05 22:55:45+00:00", "updated_at": "2026-10-05 23:18:09.164539+00:00", "lang": "en", "topics": ["ai-tools", "large-language-models", "developer-tools", "ai-agents"], "entities": ["Anthropic", "Claude", "Message Batches API", "Messages API"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/claude-message-batches-what-to-do-with-each-result-state", "markdown": "https://wpnews.pro/news/claude-message-batches-what-to-do-with-each-result-state.md", "text": "https://wpnews.pro/news/claude-message-batches-what-to-do-with-each-result-state.txt", "jsonld": "https://wpnews.pro/news/claude-message-batches-what-to-do-with-each-result-state.jsonld"}}