Dev stores

A developer-owned dev store with its own test keys, a simulated payment page, and nothing that can reach a real customer.

Create a dev store: your own standalone sandbox for building against the API. Build against it first. Its orders never touch real money, real customers or real deliveries, and its keys cannot reach a live store.

There is no flag to flip on a live request. Test mode is a property of the store your key belongs to, which is what makes the containment below hold everywhere at once.

Creating one

You create it in the Queek dashboard under Developers → Dev stores → Create, and it is yours as a developer — never a copy of a live merchant store, and never promotable to one. Creating a dev store:

starts empty, with a slug of your choosing (the suggested one is your name plus -dev). Generate test data seeds a dedicated edge-case fixture set — never a template clone, never a merchant's catalogue;
hands you its first key, a private sk_test_ one, and a storefront password (shown at creation and re-viewable by you afterwards). The storefront stays password-protected: a dev store can never be made public;
is capped per developer. Delete one to make room for the next.

The lifecycle after that is open it (admin_url), rename it, and delete it.

Test keys

Test keys carry _test_ where live keys carry _live_:

Key	Reaches
`sk_test_…`, `pk_test_…`	the dev store only
`sk_live_…`, `pk_live_…`	the live store only

Any key minted for the dev store carries _test_: the prefix is derived from the store at mint time, and checked against the store on every request. A key never crosses modes: a _test_ key on a live store, or a _live_ key on a dev store, is a 401 api_key_mode_mismatch. Going live is swapping the key — no path, header or body changes.

Everything else — X-Client-Key, origins, rate limits, the reference — is identical.

curl -i https://client.usequeek.com/v1/store/info \
  -H "X-Client-Key: sk_test_your_key_here" \
  -H "Accept: application/json"
# …
# X-Queek-Mode: test

Telling the two apart

Every response served for a dev store carries:

X-Queek-Mode: test

A live store sends no X-Queek-Mode header. The header is exposed over CORS, so browser code can read it. Log it, and refuse to start a production build against a response that carries it.

What a dev store cannot do

The point of the dev store is what it contains. Each of these is enforced server-side, not by convention:

	Dev store
Payments	No provider is ever called. Checkout hands the shopper a Queek-hosted simulated payment page where you choose the outcome: `paid` runs the same order finalisation a real provider callback runs; `declined` mirrors a failed payment. A live transaction's reference is a 404 on that page.
Messages	No email, SMS, WhatsApp or push leaves a dev store. Order confirmations, merchant notifications and channel messages are dropped before they are sent.
Discovery	A dev store is never listed in the marketplace, explore, search or any other discovery surface.
Deliveries	No delivery is requested from a courier and no rider is dispatched.
Money	No settlement, payout or ledger entry is ever booked against a dev order.
Analytics	Storefront events are accepted and dropped — nothing counts towards views or rankings.
AI	Qee and AI generation work on a dev store, billed to your own developer subscription and shared across your dev stores. The first AI call creates the free subscription automatically; when the credits run out the call is a `402`.
Own payment account	A dev store cannot enable a merchant-owned gateway (`custom_gateway_store_ineligible`).

What still works

Webhooks fire. Subscribe an endpoint to the dev store and every orders/* topic is delivered, signed, retried and logged exactly as for a live store. This is how you prove your receiver — including orders/paid, by choosing paid on the simulated payment page.
The whole read API: catalogue, content, metafields, reviews, cart.
Cart and checkout_url. The shopper walks the real Queek checkout; only the payment step is simulated.

Rename, delete, retention

Rename changes the dev store's name or slug in place. Your integration keeps working.
Delete removes the store and its keys. Create a fresh one afterwards.
Retention: a dev store's orders and analytics events older than 30 days are pruned automatically. The store and its keys are never pruned — only the scratch data ages out.

Error codes you will meet

`error.code`	Status	Cause
`api_key_mode_mismatch`	401	A `_test_` key was used against a live store or a `_live_` key against a dev store. Mint a key for the store you mean.
`ai_unavailable_in_test_mode`	403	An AI action was attempted outside a live or dev store. AI works on both.
`custom_gateway_store_ineligible`	403	A dev (or template) store tried to enable its own payment account.