# List all Orders `GET /orders` OMS API, Orders. Returns a paginated list of orders **Authentication:** Send `Authorization: Bearer `. Either an identity token issued by the auth service (dashboard flow; requires the selected merchant account id in the `X-Odus-Merchant` header), or a merchant secret key (`sk_...`) for server-to-server calls. Both are sent as `Authorization: Bearer `. ## Parameters ### Query parameters - `paymentAuthorizedAt` (filter): Send as `paymentAuthorizedAt[]=`. Operators: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `nin`. - `createdAt` (filter): Send as `createdAt[]=`. Operators: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `nin`. - `agedOutAt` (filter): Send as `agedOutAt[]=`. Operators: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `nin`. - `holdStatus` (filter): Filters orders by `holdStatus`, where they stand with a hold your fulfillment provider has put on them. `holdStatus[ne]=null` selects every order on hold. An order your provider holds because it could not charge you — your prepaid balance with NextSmartShip, or your payment method with ShipBob — is `held`, with `holdReasonCode` `insufficient_funds`. Send as `holdStatus[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `recipientFaults` (filter): Filters orders by whether they carry recorded recipient faults. Compare it with `null`: `recipientFaults[ne]=null` selects the orders with faults recorded, and `recipientFaults[eq]=null` the orders with none recorded, which includes orders not checked yet. To check one order now, call `GET /orders/{orderId}/recipient-validation`. Send as `recipientFaults[]=`. Operators: `eq`, `ne`. - `cancelledUnitsShippedAt` (filter): Filters orders by when your fulfillment provider first reported shipping units of them that you had cancelled. `cancelledUnitsShippedAt[ne]=null` selects every order with such a shipment. Send as `cancelledUnitsShippedAt[]=`. Operators: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `nin`. - `tplSubmissionStatus` (filter): Filters orders by the state of their automatic submission to your fulfillment provider: `pending`, `submitted`, `failed` (another attempt is scheduled), `dead_letter`, or a value starting with `skipped_` for an order sent to no provider. An order the provider refused because your prepaid balance with it could not cover it is on hold with `holdReasonCode` `insufficient_funds` — `submitted` when the provider has it, `failed` with nothing scheduled when it refused the order before creating it; filter on `holdStatus` for those. `dead_letter` means submission stopped: the provider refused the order, or every attempt failed. `GET /orders/{id}` returns why, in `lastSubmissionError`. If the order has shipped nothing and has no `externalOrderId`, correcting the customer’s shipping address submits it again; if the provider refuses it again, it returns to `dead_letter`. Combine with `status` to leave out orders fulfilled or cancelled since. Send as `tplSubmissionStatus[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `amount` (filter): Send as `amount[]=`. Operators: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `nin`. - `status` (filter): Send as `status[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `externalOrderId` (filter): Send as `externalOrderId[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `customerId` (filter): Send as `customerId[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `customerEmail` (filter): Send as `customerEmail[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `shippingAddress.country` (filter): Send as `shippingAddress.country[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `orderItems.paymentId` (filter): Send as `orderItems.paymentId[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `orderItems.productId` (filter): Send as `orderItems.productId[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `orderItems.sku` (filter): Send as `orderItems.sku[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `orderItems.productName` (filter): Filters orders by the product name recorded on an order item. Use `orderItems.productId` instead, which identifies a product exactly where two products share a name. Send as `orderItems.productName[]=`. Operators: `eq`, `ne`, `like`, `in`, `nin`. - `fulfillmentIntegrationType` (filter): Filters orders by who fulfills them, naming the provider (for example `shipbob`) rather than the merchant’s own connection. `none` selects orders with no fulfillment connection recorded. Several values may be given with `in`, and they are combined as alternatives. Send as `fulfillmentIntegrationType[]=`. Operators: `eq`, `in`. - `sortBy` (string): Field to sort by (default: createdAt) One of `id`, `createdAt`, `updatedAt`, `status`, `paymentId`, `amount`, `paymentAuthorizedAt`. - `sortDirection` (string): Sort direction (default: desc) One of `asc`, `desc`. - `page` (number): Page number (default: 1) - `pageSize` (number): Items per page (default: 10, max: 100) - `limit` (number): Items per page for cursor pagination (default: 10, max: 100). Sending it switches the response to cursor mode; omit it for offset pagination. - `cursor` (string): Opaque cursor from a previous response’s `nextCursor` or `prevCursor`. Only read when `limit` is present, and must be used with the same `sortBy`/`sortDirection` it was issued for. ## Responses ### `200` Type: object. - `pagination` (object (PageMetaDTO) or object (CursorPageMetaDTO)) - When the value is PageMetaDTO: - `page` (number, required) - `pageSize` (number, required) - `totalItems` (number, required) - `totalPages` (number, required) - When the value is CursorPageMetaDTO: - `mode` (constant `cursor`, required): Discriminator identifying cursor-based pagination metadata. Example: `cursor`. - `pageSize` (number, required): Number of items requested per page. Minimum 1. Example: `10`. - `hasNextPage` (boolean, required): Whether a next page exists. Example: `false`. - `hasPreviousPage` (boolean, required): Whether a previous page exists. Example: `true`. - `nextCursor` (string, required, nullable): Opaque cursor for fetching the next page. Null when there is no next page. Example: `eyJzIjoiY3JlYXRlZEF0IiwiZCI6ImFzYyIsIm4iOiJmb3J3YXJkIn0`. - `prevCursor` (string, required, nullable): Opaque cursor for fetching the previous page. Null when there is no previous page. Example: `eyJzIjoiY3JlYXRlZEF0IiwiZCI6ImFzYyIsIm4iOiJiYWNrd2FyZCJ9`. - `data` (array of object (OrderPartialDTO)) - `createdAt` (string (date-time), required): The date and time when the entity was created. Example: `2024-02-18T12:00:00Z`. - `updatedAt` (string (date-time), required, nullable): The date and time when the entity was last updated. Example: `2024-02-21T12:15:00Z`. - `metadata` (map of string to string, required, nullable): Metadata used by merchants to store additional information about the entity. - `id` (string, required) - `status` (string, required): One of `unfulfilled`, `partially_fulfilled`, `fulfilled`, `not_fulfillable`, `cancelled`. - `amount` (number, required) - `currency` (string, required): One of `usd`, `eur`, `gbp`, `cad`, `aud`, `pln`, `czk`, `sek`, `dkk`. - `customerEmail` (string, required) - `paymentAuthorizedAt` (string (date-time), required) - `agedOutAt` (string (date-time), required, nullable) - `cancelledUnitsShippedAt` (string (date-time), required, nullable): When your fulfillment provider first reported shipping units of this order that you had cancelled, for example by refunding the payment. The cancelled units stay cancelled and do not count as fulfilled. Each such shipment is in the order history as a `cancelled_units_shipped` entry with its tracking number and the units it carried, so you can recover the goods or charge for them. `null` when no cancelled units have shipped. Once set, it stays set. - `tplSubmissionStatus` (string, required, nullable): Where the order stands in its automatic submission to your fulfillment provider. `pending`: waiting to be sent. `submitted`: the provider accepted the order. `failed`: an attempt failed, and another is scheduled — or, while the order is on hold with `holdReasonCode` `insufficient_funds` and no `externalOrderId`, none is until your prepaid balance with the provider covers the order. `dead_letter`: submission stopped, and the order needs you. A value starting with `skipped_`: no provider receives the order, for example because no fulfillment route matches it. `null` when the order was never scheduled for submission. `GET /orders/{orderId}` returns when the next attempt is due, in `submitToTplAt`, and why the last one failed, in `lastSubmissionError`. The value is not cleared when you fulfill or cancel the order yourself, so read it together with `status`. Values may be added, so treat one you do not recognise as not sent yet. One of `pending`, `submitted`, `failed`, `dead_letter`, `skipped_no_route`, `skipped_no_country`, `skipped_no_shippable_items`, `skipped_route_conflict`, `skipped_integration_inactive`, `skipped_order_cancelled`. Example: `submitted`. - `holdStatus` (string, required, nullable): Set while the order is on hold: the fulfillment provider has it and is not shipping it, or it refused the order before creating it. Usually the provider put it on hold itself — it could not get a carrier to take the shipment — and waits for you to act. When the provider found no shipping option for the order, the hold is recorded here from the first attempt and the order is re-quoted automatically for a while; it is released once the provider accepts a fulfillment request, and you can resubmit it at any time meanwhile. When the provider refused the order because your prepaid balance with it could not cover it, the hold is recorded here too (`holdReasonCode` `insufficient_funds`), and the order is sent again automatically once the balance covers it. Usually the provider has such an order (`externalOrderId` is set, `tplSubmissionStatus` is `submitted`) and the hold is released once it accepts the order; when the provider refused it before creating it, `externalOrderId` is empty, `tplSubmissionStatus` is `failed` with nothing scheduled, and the hold is released when the order is sent again. When ShipBob holds the order — for an address it cannot validate, missing customs details, a payment method it could not charge, a hold placed by hand or any other reason it gives — the hold is recorded here too, with ShipBob’s reason, while the order still owes fulfillment here or is already on hold: a hold ShipBob raises after you have fulfilled or cancelled the order here is not recorded, and one recorded before that stays until ShipBob releases it. Resolve it in ShipBob, which ships the order itself once it releases the hold, and the hold is released here then. ShipBob is never sent such an order a second time. `held`: fix what `holdReason` names, then resubmit the order — or correct the customer, which resubmits it for you for most reasons (see `holdReasonCode`); for an order ShipBob holds, fix it in ShipBob instead, or correct the customer when `holdReasonCode` is `address_invalid`. Resubmitting that one sends ShipBob the address the order carries and leaves it `held`. `resubmitted`: the order was resubmitted and the provider has not answered yet; it clears when the provider accepts the order, or returns to `held` with a new reason. A correction to the customer made while the order is `resubmitted` is sent for you if the provider holds the order again for a reason that correction fixes. `null` when the order is not on hold. Independent of `status`, which the hold does not change. `held` applies to orders fulfilled through NextSmartShip or ShipBob, and `resubmitted` to orders fulfilled through NextSmartShip. Values may be added, so treat one you do not recognise as on hold. One of `held`, `resubmitted`. Example: `held`. - `holdReason` (string, required, nullable): Why the order is on hold. Usually the reason the fulfillment provider gave, in its own words — typically what the carrier refused about the address. For an order ShipBob holds, it is how ShipBob describes the hold, such as `Invalid Address`. When the provider gave no reason — it found no shipping option for the order, was never asked to ship it, could not charge your prepaid balance for it, or could not charge your payment method for it — the reason describes that instead. Kept while the order is `resubmitted`; `null` when the order is not on hold. Example: `City does not match the postal code`. - `holdReasonCode` (string, required, nullable): Why the fulfillment provider holds the order, as a code your integration can act on instead of reading `holdReason`. `null` when the order is not on hold. The same `holdReason` always has the same code. Codes may be added, so treat one you do not recognise as `other`. Correct what the code names, then resubmit the order. When the correction is to the customer — their name, phone number or shipping address — the order is resubmitted for you, except for `tax_id_missing`, `customs_details_invalid`, `shipping_restricted`, `carrier_unavailable`, `insufficient_funds`, `unspecified` and `other`. An order ShipBob holds is the exception to both: correct what the code names in ShipBob, which ships the order itself once it releases the hold. ShipBob is never sent such an order a second time, so resubmitting one is refused, except for `address_invalid`. For `address_invalid` you can correct the customer instead, unless you cancelled some of the order’s items or recorded a shipment of it yourself: their corrected name, phone number and shipping address are sent to ShipBob, which validates the address again, and the order’s history records ShipBob’s answer. Resubmitting such an order sends ShipBob the address the order already carries, in the same way. A correction for any other code is not sent to ShipBob. The codes: - `postal_code_invalid`: the postal code is not valid for the country. Correct it. - `postal_code_city_mismatch`: the city and the postal code do not match. Correct whichever is wrong. - `postal_code_not_served`: the carrier does not deliver to the postal code. Confirm it with the customer, and ask your provider for a carrier that delivers there. - `state_invalid`: the state, province or region does not match the postal code or the country. Correct it. - `street_not_found`: the carrier cannot find the street. Check its spelling, and put the street and house number on the first address line. - `house_number_missing`: the street address has no house or building number. Add it. - `address_incomplete`: the address is missing details, such as the house number or the apartment. Complete it. - `address_invalid_characters`: the address contains characters the carrier does not accept. Rewrite it in Latin letters and digits. - `name_or_address_too_long`: the recipient’s name, company or an address line is longer than the carrier accepts. Shorten it, moving the rest of a long street to the second line. - `po_box_not_accepted`: the carrier does not deliver to PO boxes. Replace the PO box with a street address. - `address_invalid`: the provider could not validate the shipping address and did not say which part of it is wrong. Check the whole address and correct it. - `recipient_name_invalid`: the recipient’s name is too short or is not a name. Enter their full first and last name. - `phone_invalid`: the phone number is not valid. Correct it, including the country code. - `tax_id_missing`: the destination country requires the recipient’s tax ID. Add it to the order in your provider’s dashboard. - `customs_details_invalid`: the provider or its carrier needs customs details the order does not have, such as a product’s material, use or HS code. Complete them in your provider’s dashboard. - `shipping_restricted`: the provider’s or the carrier’s rules do not allow this shipment, for example hazardous items shipped abroad. Ask your provider how to ship it. - `carrier_unavailable`: the carrier is temporarily unavailable. Nothing on the order needs correcting; resubmit it later. - `no_shipping_options`: no carrier offered to ship the order. Check the address, and that the items can be shipped to the country. - `fulfillment_not_requested`: the provider has the order but was never asked to ship it. Check the address. - `refused_before_fulfillment`: the provider refused the order before it was asked to ship it, and gave no reason. Check the address. - `insufficient_funds`: the provider could not charge you for the order, so it is not shipping it yet. Nothing on the order needs correcting, and `holdReason` says what could not be charged. If it was your prepaid balance with the provider (NextSmartShip), top up the balance: the order is sent again automatically once the balance covers it. To send it sooner, resubmit it while `externalOrderId` is set, or retry it with `POST /orders/{orderId}/retry-submission` while it is empty. If it was your payment method (ShipBob), update the payment method with the provider, which ships the order itself once a payment goes through. Such an order cannot be resubmitted or retried. - `unspecified`: the provider gave no reason. Look the order up in your provider’s dashboard. - `other`: no code covers the reason yet. Read `holdReason`. ShipBob’s holds for a pick date, a hold placed by hand, a packaging preference not set and an automatic processing pause read `other`, with ShipBob’s description in `holdReason`. One of `postal_code_invalid`, `postal_code_city_mismatch`, `postal_code_not_served`, `state_invalid`, `street_not_found`, `house_number_missing`, `address_incomplete`, `address_invalid_characters`, `name_or_address_too_long`, `po_box_not_accepted`, `address_invalid`, `recipient_name_invalid`, `phone_invalid`, `tax_id_missing`, `customs_details_invalid`, `shipping_restricted`, `carrier_unavailable`, `no_shipping_options`, `fulfillment_not_requested`, `refused_before_fulfillment`, `insufficient_funds`, `unspecified`, `other`. Example: `postal_code_city_mismatch`. - `heldAt` (string (date-time), required, nullable): When the current hold was detected. A resubmission that is held again starts a new hold with its own timestamp. `null` when the order is not on hold. - `recipientFaults` (array of object, required, nullable): Problems with the recipient details — name, company, address and phone — that would make NextSmartShip hold or refuse the order, as of the latest check. Each names the detail and the rule it breaks, never the value. The order is checked when it is created, when a change to the customer’s details reaches it, and each time it is submitted automatically; adding, activating or deactivating an integration does not re-check existing orders. `null` when the order has not been checked yet, when the latest check found nothing, or when it did not apply NextSmartShip’s rules because the order was sent to another provider, or had not been sent while you had no active NextSmartShip integration. Always `null` once the order is fulfilled or cancelled. To check an order now, call `GET /orders/{orderId}/recipient-validation`. - `field` (string, required): The recipient detail at fault. `name` is the first and last name together, and `address` is both address lines together. One of `first_name`, `last_name`, `name`, `company`, `address`, `address_line_1`, `address_line_2`, `city`, `state`, `postal_code`, `country`, `phone`. Example: `city`. - `rule` (string, required): The rule the detail breaks. `missing`: the provider does not accept the order without it, so the order is not sent while it is missing. `placeholder`: a stand-in such as `N/A` rather than a real value. `no_latin_form`: the text has no Latin-alphabet form to print on a shipping label. `too_long`: longer than the provider accepts, after any shortening the rules apply to names and addresses. `too_short`: shorter than the provider accepts. `invalid_format`: not a valid postal code for the country. `postal_code_mismatch`: the city is not a locality of the postal code. `unrecognized`: neither the state nor the postal code identifies a state or province. Every rule but `missing` still lets the order be sent, and the provider is likely to hold it. One of `missing`, `placeholder`, `no_latin_form`, `too_long`, `too_short`, `invalid_format`, `postal_code_mismatch`, `unrecognized`. Example: `postal_code_mismatch`. - `orderItems` (array of object, required) - `createdAt` (string (date-time), required): The date and time when the entity was created. Example: `2024-02-18T12:00:00Z`. - `updatedAt` (string (date-time), required, nullable): The date and time when the entity was last updated. Example: `2024-02-21T12:15:00Z`. - `metadata` (map of string to string, required, nullable): Metadata used by merchants to store additional information about the entity. - `id` (string, required) - `name` (string, required) - `productName` (string, required) ### `202` 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. Type: object (ProvisioningInProgress). - `status` (string, required): Signals the merchant OMS environment is still being provisioned. One of `provisioning`. - `merchantAccountId` (string, required): The merchant account whose OMS environment is being provisioned. Example: `dAI3aa87ROOeupeBCjNSKCOBOisBCYjB`. ### `400` 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. Type: object (ValidationErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): The first error message from the validation errors. Example: `note must be a string`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. - `errors` (array of string): Complete list of validation errors. ### `401` No credentials were supplied, or the identity token / secret key is not valid for the target merchant. `type` is `authentication_error`. Type: object (ErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): Human-readable description of the failure. Example: `An error occurred`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. ### `403` The credentials are valid but lack the permission this operation requires. `type` is `permission_error`. Type: object (ErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): Human-readable description of the failure. Example: `An error occurred`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. ### `429` Too many requests. The rate limit is applied per client across all operations. `type` is `rate_limit_error`. Type: object (ErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): Human-readable description of the failure. Example: `An error occurred`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. ### `500` The request could not be completed because of an unexpected error. `type` is `api_error`. Type: object (ErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): Human-readable description of the failure. Example: `An error occurred`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. ### `503` 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. Type: object (ErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): Human-readable description of the failure. Example: `An error occurred`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. ### `504` 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. Type: object (ErrorResponse). - `statusCode` (number, required): HTTP status code. Example: `400`. - `requestId` (string, required): Unique identifier for the request. Example: `dfc10de3-36bb-4bcc-b081-316216194033`. - `message` (string, required): Human-readable description of the failure. Example: `An error occurred`. - `type` (string, required): Coarse, stable classifier for the failure. Present on every error response including 5xx. This is the field to branch on: `statusCode` is too coarse and `message` is human prose that may be reworded. The set is closed and every member is permanent, so it is safe to handle exhaustively. One of `invalid_request_error`, `authentication_error`, `permission_error`, `not_found_error`, `invalid_state_error`, `conflict_error`, `rate_limit_error`, `payment_error`, `api_error`. Example: `invalid_request_error`. - `code` (string): Fine-grained identifier for the failure, present only where it adds something `type` does not — for example separating a replayed idempotency key from a held lock, or naming the reason a payment was declined. The set is open and grows over time, so treat an unrecognised value as absent and fall back to `type`. Example: `validation_failed`. --- Generated from the OMS API OpenAPI document, https://sandbox-oms-api.odus.com/openapi.json. Interactive page: https://docs.odus.com/docs/api/oms/order-controller-find-all-paginated