pauseStores

POST/management/store-status/pauseStores

Take one or more storefronts offline, with a typed reason and an optional automatic reopen time (ONE-2620, Phase 1's first WRITE). The guest-facing message on platforms that accept free text is exactly your note — never a synthesized string.

Stores are processed independently: one unsupported storefront in the batch does not fail it. 422 is returned only when NO store in the batch supports the action through the API (today: none of the requested ids has live platform credentials).

Scope: only storefronts your organization owns or operates a brand out of. A storeId that exists but belongs to another organization is INDISTINGUISHABLE from one that does not exist at all — both are simply absent from the response, never mutated.

reason: 'other' requires note.

Request

application/json

required

storeIdsstring[]
Store.id values, 1-100.
reasonstring
Typed reason — required. 'other' requires note.
Possible values: [closingEarly, problemInRestaurant, outOfItems, tooBusy, other]
notestring
Required when reason is 'other'; shown where the platform accepts free text.
untilstring<date-time>
Automatic reopen time. Omit for an indefinite pause.

{
  "storeIds": [
    "<storeIds>"
  ],
  "reason": "closingEarly",
  "note": "<note>",
  "until": "2026-01-01T00:00:00Z"
}

Responses

200 — OK

statusesStoreStatus[]
One entry per requested storefront your organization operates that supports pausing through the API, carrying only storeId and the desired state just written. Requested ids that are not yours, or not integrated, are omitted.

About Store status

Whether each storefront is actually taking orders — and whether OneTablet and the delivery platform agree about it.

SPLIT OUT OF Stores BY ONE-2736. Stores is the identity map: the brands, kitchens and storefronts you operate, which changes when your estate changes. This section is the OPERATIONAL layer on top of it — one read (fetchStoreStatuses), two writes (pauseStores, unpauseStores) and the store.status.changed webhook — all addressed by the Store.id values fetchStores hands you. Same api key, same org scoping, same ids; a different job, and a different route prefix (/management/store-status) so the url says which.

Three things are kept distinct throughout, and conflating them is the mistake this section exists to prevent: desired is what OneTablet is configured to do, observed is what the platform reports, and discrepancy is the classified disagreement between the two.

Org-scoped to the organization your api key resolves to, exactly as the directory reads are.