Retry sending an order to its fulfillment provider
POST/orders/:orderId/retry-submission
Sends an order your fulfillment provider could not take to the provider again, with the shipping address and customer details the order carries now: a tplSubmissionStatus dead_letter order, or one on hold with holdReasonCode insufficient_funds that the provider does not have (externalOrderId is empty). If the provider refused the order for its customer details, correct them first, then retry. An order the provider refused for lack of prepaid funds is sent again automatically once your balance with the provider covers it; to send it sooner, for example right after you top up, resubmit it with POST /orders/{orderId}/resubmit while the provider has it (externalOrderId is set), or retry it here while it does not. The order is sent shortly afterwards, usually within minutes, rather than during this request: tplSubmissionStatus becomes failed with submitToTplAt set, then submitted once the provider accepts the order. If the provider refuses it again, it returns to dead_letter with the new reason in lastSubmissionError, or goes on hold for funds if your balance still cannot cover it; a provider that cannot be reached is retried automatically, as on the first submission, until the order runs out of attempts. Only an unfulfilled order can be retried, and only while the provider does not already have it (externalOrderId is empty). Retry only an order you have not shipped some other way, for example by importing it into your provider yourself: a retry sends it again. The order's history records the retry and the provider's answer.
Request
Responses
- 200
- 202
- 400
- 401
- 403
- 404
- 429
- 500
- 503
- 504
The merchant is entitled but its OMS environment is not provisioned yet. Provisioning has been kicked off (exactly once) and is in progress; retry the request — it succeeds once the environment is ready. Returned only for identity-token (dashboard) requests bound to an active-entitled merchant, not for secret-key API calls; any such endpoint can return it while provisioning is underway.
The request was rejected. type is invalid_request_error; when the failure is a validation failure code is validation_failed and errors lists every problem found, with field-attributable entries prefixed by the field’s path.
No credentials were supplied, or the identity token / secret key is not valid for the target merchant. type is authentication_error.
The credentials are valid but lack the permission this operation requires. type is permission_error.
No resource exists with the requested identifier. type is not_found_error.
Too many requests. The rate limit is applied per client across all operations. type is rate_limit_error.
The request could not be completed because of an unexpected error. type is api_error.
A dependency needed to serve the request is temporarily unavailable — for every operation the auth service that verifies credentials and resolves entitlement, and on the provisioning routes also the ODUS API the OMS reconciles against. type is api_error. Unlike a plain 500 the condition is transient rather than a fault in the request, so it is worth retrying with backoff.
The request exceeded the processing time limit and was abandoned. type is api_error and code is timeout — unlike a plain 500 the request may still have taken effect.