The blocks of one ready-made section, built from this shop
- Credentials
- OAuth access token
- Scopes
design:write- Role
- Owners and admins only. Staff get
403 forbidden. - Plan
- Growth. A plan without it gets
403 plan_limit.
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.
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.
sectionId*stringA ready-made section id, as the page editor offers them.
OK
application/json- response
data*curl -X GET 'https://api.shopeazy.co/v1/merchant/stores/<storeId>/pages/sections/<sectionId>' \ -H 'Authorization: Bearer <access_token>'{ "data": { "sectionId": "string", "blocks": [ {} ] }}Publish, unpublish or delete several pages POST
Up to 200 pages, one at a time (each change rewrites the store's pages index in a transaction, so running them side by side would only make them retry). Each page is re-read and decided again: one that is gone, already in that state, or that the plan does not allow is left alone with the reason. `delete` is permanent. The answer is one `{ id, ok, error? }` per id (`BulkResult`), always 200. A retry is safe: a page already published, unpublished or deleted is left alone (`ok: false`, for example `already live` or `not_found`) and nothing happens twice; the same `Idempotency-Key` replays the first answer. Access: OAuth scope `design:write`; owner/admin only; write-gated by the subscription.
Switch a catalogue page to a designed page, or back PUT
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.