Switch a catalogue page to a designed page, or back
- Credentials
- OAuth access token
- Scopes
design:write- Role
- Owners and admins only. Staff get
403 forbidden. - Subscription
- Needs an active plan. Otherwise
403 subscription_locked. - Idempotency
- Send an
Idempotency-Keyheader. A retry with the same key does the work once.
Design, Page headers, "Design this page": the page that lists everything of one kind (physical is the shop, service, ticketing, tour) becomes a page you design, or goes back to the built-in one. Every plan. Switching on creates the designed page (a draft built around the listings) and answers its id; switching to the state it is in answers the same page again, so a retry is safe.
Access: OAuth scope design:write; owner/admin only; write-gated by the subscription.
merchantOAuth design:writeAuthorizationBearer <token>OAuth 2.1 (authorization code + PKCE S256, public clients, dynamic registration) for connected AI apps. Effective power is scopes granted AND the person's role today AND the plan. orders:refund, billing:write and team:write are opt-in on the consent screen. Write implies read for marketing:read and messages:read, so a grant holding marketing:write passes a marketing:read check, and messages:send passes messages:read.
Scope: design:write
storeId*stringA store the person can reach. Any other id answers 404, never 403.
kind*stringThe kind of listing whose catalogue page this is.
"physical""service""ticketing""tour"Idempotency-Key*stringRequired on every write. Minted on the device when the person taps, reused on every retry. A write without one, or with one that does not match the pattern, is refused with 422 validation_error. Scoped to the token's subject, remembered 24 hours. A replay returns the first 2xx response with Idempotent-Replay: true; a request still running answers 409 in_flight; the same key with a different method, path or body answers 409 idempotency_key_reused; non-2xx results are not remembered. If the key store cannot be read nothing is processed and the answer is 503 idempotency_unavailable: retry with the same key.
^[A-Za-z0-9_-]{8,128}$application/json- body
designed*booleantrue: the kind's page (shop, services, events, tours) is a designed page you edit; false: back to the built-in page.
OK
application/json- response
data*curl -X PUT 'https://api.shopeazy.co/v1/merchant/stores/<storeId>/pages/catalog/<kind>' \ -H 'Authorization: Bearer <access_token>' \ -H 'Idempotency-Key: <unique_key>' \ -H 'Content-Type: application/json' \ -d '{ "designed": false}'{ "data": { "pageId": "string" }}The blocks of one ready-made section, built from this shop GET
A section (a hero, best sellers, reviews, ...) is turned into blocks from the shop's own data, on the server, so the plan is checked and nothing points at a listing that has just gone. The blocks are returned, not saved: put them in a draft with `savePage`. An unknown `sectionId` is 400 `bad_request`; a shop without what the section needs yet (for example no listings) is 422 `validation_error`. Plan: Growth (403 `plan_limit` below it, naming the section). It writes nothing and spends no credits: despite the "AI section" label in the ticket it is deterministic, so it is a GET with no `Idempotency-Key`; AI-written pages are `buildPageWithAi`. Below Growth only the Starter sections (`bestsellers`, `meet-the-maker`, `visit-us`) are built. Access: OAuth scope `design:write`; owner/admin only; not write-gated.
The order pages appear in the menu and footer PUT
Page ids, first to last. Pages left out keep their place after these. Access: OAuth scope `design:write`; owner/admin only; write-gated by the subscription.