Merchant API overview
The server-side API for a store's own systems — stock sync, fulfilment, catalogue.
The Merchant API is how a store's own servers read and write its Queek data: an ERP pushing stock levels, a fulfilment service moving orders through statuses, a catalogue tool creating products, collections and discounts. It is the server-side counterpart to the Storefront API — which serves shoppers — and it never touches checkout, payment or delivery directly.
Every snippet below is a complete request. Put a real key in it and it runs.
Get a private key
The merchant mints it in the Queek dashboard, under Settings → API keys
(the Connections list), and hands it to you. It is a private sk_live_… key —
sk_test_… on a dev store — bound to one store, carrying
exactly the scopes the integration needs. There is no
OAuth flow and no token exchange: the key is the credential.
Servers only
The key authenticates alone and acts for the whole store. Keep it on your
server — never in browser code, an app bundle, or a public repository. A public
pk_ key is a browser credential and is refused here.
Make the first request
Every call carries the key in X-Client-Key, and the base URL is
https://api.usequeek.com/api/v1/merchant. No vendor header, no vendor_id: the
key already names its store.
curl https://api.usequeek.com/api/v1/merchant/store \
-H "X-Client-Key: sk_live_..." \
-H "Accept: application/json"GET /store is the one call you always make first. It returns the store
you are acting for — if the key is wrong, this is where you find out.
Do the store's work
Read the scopes table for what each operation needs, then work through the reference:
- Catalogue — products, variants, images, collections, metafields and metaobjects, posts and shipping zones.
- Stock — the inventory overview and history, and the single stock write:
POST /inventory/adjustments. - Orders — list and read them, update their status, assign a rider.
- Customers — list and read them. Contact fields stay masked unless the key holds the contact scope.
Writes take an Idempotency-Key so a retry cannot execute twice — see
Idempotency & rate limits. Use the
safe integration checklist for cursor reads,
retry decisions, and error handling. Every failure answers in the
error envelope; branch on error.code.
Stay in sync with events
Do not poll. Subscribe an endpoint per store and Queek posts signed order events to it — the webhooks are shared with the storefront, same topics, same verification, same retries. This API moves the store's state; webhooks tell you when the shopper or checkout moved it first.
Where to go next
Authentication & keys
The private key alone, one store per key, scopes as permission, and what each refusal means.
Scopes
The scopes and operations each unlocks, generated from the spec.
Idempotency & rate limits
Retry writes safely, and understand the per-key, per-plan quota.
Building safe integrations
Cursor reads, retries, error handling, and an integration checklist.
Merchant endpoint reference
Every operation, parameter and response, generated from the merchant OpenAPI spec.
Errors
The one envelope, every code this API emits, and the retries that are safe.
Webhooks
Order events pushed to your server, signed with Standard Webhooks.
Import spec/merchant-openapi.json — the snapshot this reference is generated
from — into Postman or Insomnia to explore the API interactively.