STORE_CLOSED
STORE_CLOSED
The store is not accepting orders at the time of the request — either outside posted hours, manually closed by the operator, or under a temporary capacity hold.
Summary
| Field | Value |
|---|---|
| Appears as | errors[].code |
| Response | HTTP 200 — Order with isValid: false and a populated errors[] |
| Retry immediately | No |
This is a reason code, not a top-level error code
STORE_CLOSED is an errors[].code value on the order. It is not a top-level
ProblemDetail.errorCode, so it carries no HTTP status, errorCategory, or retryable field of its
own. See Unified OrderError shape.
When This Fires
POST /v1/marketfront/orders/validatePOST /v1/marketfront/orders/place
Both endpoints surface this identically. It originates with the commerce partner rather than with Gett — there is no Gett-side store-hours pre-flight, so the partner's response is the only authority, and a store can transition to closed between your validate and your place.
Not to be confused with STORE_PAUSED
When Gett blocks an order because a store is paused on our side, that is a different code in the
other vocabulary: a top-level STORE_PAUSED with HTTP 409. Handle both — they mean "this store
cannot take the order now" but arrive in different shapes.
Recommended Action
Do not retry the same store immediately. Instead:
- Re-call store availability (
GET /v1/marketfront/stores/{storeId}or re-run discovery for the user's address) to confirm current open hours. - Surface a "closed" affordance to the user with the next-open time if available.
- Offer alternative stores from a fresh discovery call.
A retry is only appropriate after the store's next-open time, and even then a fresh availability check should precede order submission.
Example
Code