Read results at row level
Match each returned result to the original internal request reference. A successful HTTP response may contain individual business errors, while a transport error may leave acceptance uncertain. Use the documented response format rather than one overall success flag.
Separate three outcomes
Classify rows as accepted with an order ID, explicitly rejected with a reason, or unresolved. These categories require different next steps. Accepted rows should proceed to monitoring; rejected rows may need corrected inputs; unresolved rows need reconciliation before retry.
Preserve batch history
Keep the original file or request references and append retry outcomes. Do not overwrite the first result with a later attempt, because staff may need to understand how many external orders were created. Recalculate spending from accepted records.
Decision checklist
| Decision | What to check |
|---|---|
| Accepted | Provider order reference |
| Rejected | Explicit business error |
| Unresolved | Acceptance not known |
Worked example
A hypothetical batch of ten requests returns seven order IDs, two quantity errors, and one timeout. Retrying all ten risks duplicating seven accepted purchases. Correct the two rejected inputs and investigate the timeout separately.
Example figures explain the decision; they are not current prices or promised results.