Save "You deliver": the shop's own delivery zones
- Credentials
- OAuth access token
- Scopes
settings: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.
Replaces the zones the shop had, so a removed zone does not linger. Every zone is checked and a refusal says what to fix (a zone needs a name and a price; only one can be "everywhere"; a cut-off is like 12:00). Answers with the settings as saved.
Access: OAuth scope settings:write; owner/admin only; write-gated by the subscription.
merchantOAuth settings: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: settings: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
enabled*booleanzones*array<>items <= 50beyond?stringPast every zone: no delivery, or a connected courier.
"none""courier"days?array<>0 = Sunday ... 6 = Saturday.
items <= 7cutoff?stringSame-day cut-off, like 12:00.
leadDays?integer0 <= value <= 30freeOverMinor?integer0 <= valueshowDay?booleanShow the promised delivery day at checkout. Absent = yes.
OK
application/json- response
data*curl -X PUT 'https://api.shopeazy.co/v1/merchant/stores/<storeId>/delivery/self-delivery' \ -H 'Authorization: Bearer <access_token>' \ -H 'Idempotency-Key: <unique_key>' \ -H 'Content-Type: application/json' \ -d '{ "enabled": false, "zones": [ { "name": "string", "match": { "kind": "radius", "maxKm": 1 }, "priceMinor": 1 } ]}'{ "data": { "enabled": true, "zones": [ { "id": "string", "name": "string", "enabled": true, "match": { "kind": "radius", "maxKm": 1 }, "priceMinor": 0, "tiers": [ { "belowMinor": 1, "priceMinor": 0 } ], "freeOverMinor": 0, "minOrderMinor": 0, "days": [ 0 ], "cutoff": "string", "leadDays": 0 } ], "beyond": "none", "days": [ 0 ], "cutoff": "string", "leadDays": 0, "freeOverMinor": 0, "showDay": true }}Roughly what dropping off saves against a driver collecting GET
Priced for the store's default parcel to where its customers actually are (its most recent delivery address), because a saving to nowhere in particular is a number nobody can trust. Asks the courier for two rates; if it cannot be reached the answer is `saving: null`, never an error. A read, so it is not write-gated. Access: OAuth scope `store:read`; not write-gated.
Move an order the shop delivers itself POST
`out_for_delivery` marks the lines sent and emails the customer it comes today; `delivered` can say who took it; `not_delivered` needs a reason and goes to Problems. Answers with the order as it now stands. Access: OAuth scope `delivery:write`; write-gated by the subscription.