Publish, unpublish or delete several pages
- 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.
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.
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.
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
op*stringThe same as publishPage, unpublishPage and deletePage, on each page.
"publish""unpublish""delete"ids*array<string>The pages to act on, at most 200 (the console's cap). Repeated ids are counted once.
1 <= items <= 200OK
application/json- response
data*The answer to every bulk operation. One item failing never stops the rest, so the call is 200 even when some or all were left alone; read items.
curl -X POST 'https://api.shopeazy.co/v1/merchant/stores/<storeId>/pages/bulk' \ -H 'Authorization: Bearer <access_token>' \ -H 'Idempotency-Key: <unique_key>' \ -H 'Content-Type: application/json' \ -d '{ "op": "publish", "ids": [ "string" ]}'{ "data": { "items": [ { "id": "string", "ok": true, "error": { "code": "string", "message": "string" } } ], "done": 0 }}A landing page built around one listing POST
A draft page with the listing's photos, details and a buy button, for ads and social links. Growth and Scale. Access: OAuth scope `design:write`; owner/admin only; write-gated by the subscription.
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.