Quickstart
Read a store's catalogue with an API key, then hand a cart to Queek checkout.
The Queek Storefront API serves one business that sells on Queek. Its products, collections, promotions, reviews, pages and blog already exist; you read them and manage a cart. Queek runs checkout, payment and delivery — your code never touches payments.
Every snippet below is a complete request. Put a real key in it and it runs.
Get an API key
The merchant creates the key in the Queek dashboard, under Settings → API keys, and hands it to you. There are two kinds:
| Key | Where it belongs | Origin |
|---|---|---|
pk_live_… | browser code — shipped in the bundle, visible to anyone | only works from an origin on the key's allowlist |
sk_live_… | servers, SSR and build-time fetches, native apps | needs no Origin; never ship it to a browser |
Building the whole site, including from a terminal?
Ask the merchant for a public key whose allowed origins are *. It works from any origin
and from none — your terminal, a sandbox, the browser — so nothing locks you out mid-build.
The merchant replaces * with the real domain once the site has one.
Make the first request
Every call carries the key in X-Client-Key, and the base URL is
https://client.usequeek.com/v1.
curl https://client.usequeek.com/v1/store/info \
-H "X-Client-Key: pk_live_your_key_here" \
-H "Accept: application/json"store/info is the one call you always make first. It returns the store's name, slug,
currency, opening hours and address — and, on your own key, storefront_url, checkout_url,
unmasked contact, and the brand kit (logo, colour tokens, fonts, socials) you build the
site's look from.
Testing an origin-restricted public key from a script? Send an allowlisted origin with it:
-H "Origin: https://the-store.example".
Read the catalogue
curl "https://client.usequeek.com/v1/store/products?per_page=20&page=1" \
-H "X-Client-Key: pk_live_your_key_here"Walk the whole catalogue with page, using pagination.current_page and
pagination.last_page from the reply — that is how you build listings, sitemaps and static
pages. keyword, category_slug, sort and has_video narrow it down; per_page caps at
100.
Every price you receive is the final customer price in the store's currency. Display
it as given; never recompute it.
Identify products, categories and collections by the slug or id a listing returned. Never
invent one.
Take the first order
Generate one random UUID per shopper and send it as X-Cart-Session on every cart call.
That header is the cart's identity.
curl -X POST https://client.usequeek.com/v1/store/cart/items \
-H "X-Client-Key: pk_live_your_key_here" \
-H "X-Cart-Session: 3f1a8e64-4f2c-4a1d-9d2e-2f7b0c8a5d11" \
-H "Content-Type: application/json" \
-d '{"product_id": "the-id-from-a-listing", "quantity": 1}'If the reply comes back result: "customise", the product needs a variant or addon choice:
show the options it returned and call again with variant_id.
Before you send the shopper anywhere, re-check the cart against current stock and prices:
curl -X POST https://client.usequeek.com/v1/store/cart/validate \
-H "X-Client-Key: pk_live_your_key_here" \
-H "X-Cart-Session: 3f1a8e64-4f2c-4a1d-9d2e-2f7b0c8a5d11"Every cart reply carries checkout_url. Send the shopper there —
window.location = checkout_url — and Queek shows exactly this cart and completes address,
delivery, payment and order confirmation.
That is the whole checkout integration. There is no order-creation endpoint to call and no payment step to implement.
Where to go next
Authentication
Public vs private keys, origins, rate limits and what each failure means.
Endpoint reference
Every endpoint, parameter and response, generated from the live OpenAPI spec.
Webhooks
Order events pushed to your server, signed with Standard Webhooks.
Versioning & errors
What v1 guarantees, how changes are announced, and the error shape.