Copy page

Commerce Partners

Store Management

Pause and resume your stores' availability through the Commerce API.

Fulfillment Capability

Every store advertises which fulfillment types it supports via two booleans:

• deliveryAllowed — true if this store accepts delivery orders.
• pickupAllowed — true if this store accepts pickup orders.

At least one of these must be true. A catalog push that declares both as false will be rejected.

Fulfillment capability is a store-level property — it is not carried in the CatalogSet payload and does not change per menu. Set it once per store via Gett's admin tooling and update it only when the store's real-world capability changes. (Fulfillment-capability flags are admin-set; pause/resume is self-serve — see Store Status below.)

What the consumer app does with these flags

• Discovery: stores are filtered by the selected fulfillment mode. A delivery-only store will not surface for pickup-mode users, and vice versa.
• Restaurant cards: render a "Delivery", "Pickup", or "Delivery · Pickup" badge from these flags. Mode-incompatible stores are greyed out with an explanation rather than hidden.
• Cart gate: the Add-to-Cart button is disabled on mode-incompatible stores with copy that prompts the user to switch mode.
• Order placement: the backend re-validates the combination; a delivery order for a pickup-only store is rejected with a typed error.

Recommendation

If you integrate a provider whose store operating model only supports one fulfillment type, set the other flag to false on all your stores explicitly. The system defaults both to true — declaring your capability prevents surprising the end user mid-checkout.

Store Status

You can pause and resume individual stores via the Commerce API. Pausing a store removes it from discovery and rejects new orders until it is resumed.

The full request/response schemas, parameters, and try-it console are in the Store Status API Reference — this guide covers the operational behavior.

Reading the current status

Code
GET /v1/commerce/stores/{storeId}/status
Authorization: Bearer YOUR_API_KEY

Returns a StoreStatusResponse with the current status ("online" or "paused"), the optional pauseReason, and the optional resumeAt timestamp.

Pausing a store

To pause a store, POST with status: "paused". Supply a future UTC resumeAt to schedule automatic resume; omit it to pause indefinitely.

Pause until 18:00 UTC on 2026-06-20 (auto-resume):

Code
POST /v1/commerce/stores/{storeId}/status
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "status": "paused",
  "pauseReason": "Temporary kitchen closure",
  "resumeAt": "2026-06-20T18:00:00Z"
}

Pause indefinitely (no resumeAt):

Code
POST /v1/commerce/stores/{storeId}/status
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "status": "paused",
  "pauseReason": "Equipment maintenance"
}

Resuming a store

Send status: "online" to resume immediately. This clears any stored pauseReason and resumeAt.

Code
POST /v1/commerce/stores/{storeId}/status
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "status": "online"
}

Example response (either endpoint):

Code
{
  "status": "paused",
  "pauseReason": "Temporary kitchen closure",
  "resumeAt": "2026-06-20T18:00:00Z"
}

Effects of pausing

• Discovery: the store is hidden from location-based search results.
• Checkout: any attempt to place an order is rejected with error code STORE_PAUSED.
• Auto-resume: if resumeAt was supplied, the store automatically transitions to "online" at that UTC time.
• Manual resume: sending {"status":"online"} resumes immediately and clears pauseReason and resumeAt.

Rules

• pauseReason and resumeAt are only meaningful when pausing — they are ignored when status is "online".
• resumeAt must be a future ISO 8601 instant with a Z suffix (UTC).
• A status other than "online"/"paused", or a resumeAt in the past or present, is rejected with 400. An unknown store returns 404; an unrecognized API key, 403.