Storefront and content

Capabilities for storefront, content, reviews, messaging and conversations. 12 capabilities on this page: 10 available, 0 partly available, 2 not yet available. 2 more are not offered by design.

Each entry says what the capability does, what is missing or worth knowing where that applies, a workaround where there is a gap, and how you reach it. An entry marked Not offered by design says why and what to use instead. Scope names are explained on Merchant API scopes; How to read this catalogue defines the labels.

Storefront

Product-page app blocks

Available

Declared app blocks on product targets from a small schema (date, time, select, shopper text input (line_text), and one optional submit button); availability reads through the signed proxy (a line_text block needs no proxy read), the submit button posts the block’s choices to the app, other actions deep-link out.

Good to know:

• Product targets only.

• A block may declare one submit element, accepted only for an app that declares extensions.proxy.allow_post and granted by the merchant; the storefront posts the block’s other choices as one JSON object, with the product, through the signed proxy. Without the grant the block stays read-only.

• A block renders only after its read at the same path answers, so an app with a submit element must answer that read, even with an empty object. A block made only of line_text fields makes no proxy read.

• A line_text field takes shopper text up to its max_length (1 to 500, default 100); a manifest declares at most 3, a block holding one holds only line_text fields and shows on declared products only, and the text is untrusted shopper input: treat every value as such. A version that adds line_text goes through review.

• Routes: GET api/v1/client/app-placements

• Manifest: extensions.blocks

Shopper account extensions

Not yet available

Apps cannot mount on shopper account pages: there are no full-page, order, profile or block targets in the signed-in customer area.

Workaround: Serve account-adjacent features on the app-hosted page with the customer reads.

Site-wide storefront embeds

Available

Apps can display merchant-enabled, sandboxed body embeds across eligible storefront pages through a controlled iframe surface.

Good to know:

• Each embed has exactly one capability: chat bubble, banner, popup, or scroll to top.
• Embeds render in the storefront body only; apps cannot add head content or inline scripts.
• The iframe sandbox does not allow forms or popups. Link-out chat buttons such as wa.me and t.me, and native form posts, cannot work inside an embed.
• At most three embeds can be enabled per store; each embed is off until the merchant enables it.
• Embeds support the functional consent category only.
• The iframe receives no shopper or customer identity.
• The queek app deploy command rejects embeds until the developer CLI is updated.

Workaround: First-party apps can be registered through the Developer page until queek app deploy is updated to accept embeds.

• Manifest: extensions.blocks, extensions.embeds

Shopper identity to apps

Available

The proxy passes the logged-in customer id only when the app’s grant, the manifest flag, the platform switch and the shopper’s session all agree. Logged-out shoppers read as blank, and a POST carries the same identity rules as a read.

Good to know:

• There is no anonymous visitor id: a logged-out shopper reads as blank, and the id Queek passes is the store customer id, never a cross-store identity.
• The proxy has no email-capture call, and a collected email is neither proof of identity nor permission to market to that person. A storefront can subscribe a shopper to the store’s email list through the public subscribe endpoint, and an app can file what it captured as a collected record from its server.
• Apps cannot start a conversation with a shopper; they can reply to a conversation the shopper started through the conversation API.

Workaround: Read the passed customer id for signed-in shoppers. For anyone else, capture identity on the app-hosted page behind the deep link from the block.

• Routes: GET api/v1/client/apps/{appSlug}/{path}, POST api/v1/client/apps/{appSlug}/{path}
• Configuration: apps.proxy_share_customer_id_enabled

Compose storefront pages

Available

An app can list, read, create, update and delete a store’s pages and write their sections, always as drafts. The merchant reviews and publishes in the dashboard; an app cannot publish.

Good to know:

• Drafts only: a page an app creates is a draft and a change to a published page is saved as a draft beside it. An app cannot publish, schedule or unpublish, so status, published_at, is_home, template and chrome are refused.
• On a published page only sections can be written; its title, slug and SEO would change the live page, so they answer 409. A published page or the home page cannot be deleted by an app.
• Sections use the same section list the dashboard saves, limited to a safe subset for apps: no embed, video, contact or metaobjects sections, no raw HTML, links only as http(s), root-relative or #fragment (mailto: and tel: on link fields), background colour as a hex value, and no per-section tokens or dynamic-source bindings. At most 50 sections and 256 KB per page.
• The page list and read answer the live sections beside the draft sections; there is no preview link for a draft.
• The scopes merchant-pages-create, merchant-pages-update and merchant-pages-delete are review-required when added to an app version.

Workaround: Write the page as a draft through the pages API and ask the merchant to review and publish it in the storefront editor; use an app block for app-owned content in supported placements.

• Routes: GET api/v1/merchant/pages, GET api/v1/merchant/pages/{page}, POST api/v1/merchant/pages, PATCH api/v1/merchant/pages/{page}, DELETE api/v1/merchant/pages/{page}
• Scopes: merchant-pages-read, merchant-pages-detail, merchant-pages-create, merchant-pages-update, merchant-pages-delete

Storefront app proxy (read)

Available

One signed server-to-server read per shopper request, with replay rules, pinned fetch, per-install throttling and no shared caching.

Good to know:

• GET reads; writes are a separate opt-in (see storefront proxy writes). Tight body and time budgets per call.

• Routes: GET api/v1/client/apps/{appSlug}/{path}

• Configuration: apps.proxy_max_bytes

Storefront proxy writes

Available

An app that declares extensions.proxy.allow_post, and whose merchant has accepted it, receives signed JSON POSTs from the storefront at its proxy URL. The signed query carries the verb, a sha256 of the exact body and the shopper’s Idempotency-Key. A Queek-rendered product block can post its choices through a submit element.

Good to know:

• POST only, application/json only, one JSON object or array of at most 65,536 bytes; PUT, PATCH and DELETE are refused.
• Off until the app declares extensions.proxy.allow_post and the merchant accepts the update; installs made before the declaration stay read-only.
• Queek forwards the body and the signed query only: no cookies, Authorization header, client key, Origin or shopper IP reach the app. The shopper’s customer id follows the same rules as reads.
• The app’s 200, 201, 202, 204, 400, 409 and 422 answers are relayed; any other status, a non-JSON body or a timeout reads as a 424 app_proxy_failed. A timed-out POST may still have been processed, so dedupe on the signed idempotency_key.
• At most 20 submissions a minute per shopper IP and 600 a minute per installation.
• Embeds cannot post. A block posts only through its submit element, to its own proxy path, which is the same path its read uses, so an app with several blocks tells them apart by the body.
• The queek app deploy command accepts extensions.proxy.allow_post from CLI 0.15.5; older versions reject it.

Workaround: Declare allow_post and a submit element in the block schema and deploy with the queek CLI (a release newer than 0.15.5) or the Developer page. For any other surface, send the POST from storefront code on the store’s own origin or deep-link to an app-hosted page.

• Routes: POST api/v1/client/apps/{appSlug}/{path}
• Manifest: extensions.proxy.allow_post
• Configuration: apps.proxy_post_max_bytes

App-scoped product search

Available

Apps can search a store’s shopper-visible products by keyword, availability and defined metafields.

Good to know:

• Products only: this endpoint has no collection filters or results, recommendations, app-managed synonyms, total counts or facets.
• Keyword matching is a substring match on title, description or SKU with no relevance ranking, stemming or typo tolerance.
• The in_stock field in a result is the stored product value, while the in_stock filter checks active variants.

Workaround: Follow next_cursor for more products. For collections, pages and posts call the public storefront search (GET api/v1/client/store/search), which resolves the store from its host and needs no app credentials, or list collections with merchant-collections-read. Implement app-specific suggestions, synonyms and facets on the app server.

• Routes: GET api/v1/merchant/storefront/search
• Scopes: merchant-items-read

Run consent-aware tracking pixels

Not yet available

Apps have no pixel runtime for shopper events, consent-gated execution or conversion delivery.

Good to know:

• Storefront page-view tracking is not an app event subscription, and apps cannot register a pixel or receive consent-aware conversion events.
• The store itself can run Meta, TikTok and Pinterest browser pixels from ids the merchant sets (page view only, after the shopper accepts marketing cookies). An app cannot set, read or add to them.

Workaround: Ask the merchant to enter the network id in the dashboard Ad pixels card, or use the app backend for server-side events it can observe through the webhooks; do not install shopper-side tracking through Queek.

Manage storefront theme assets

Not offered by design

Queek does not let apps inject scripts into storefronts or edit theme files. Use storefront embeds and product-page app blocks instead.

Apps can register storefront blocks and use the app proxy, but cannot read or write theme files or inject arbitrary scripts.

Good to know:

• The app manifest has no theme asset or script-tag extension, and the public API has no route to read or write theme files.

Workaround: Use registered storefront blocks for app content, or ask the merchant to make theme edits in the storefront editor.

Content

Blog-post reads and markdown writes

Available

Apps can list and read blog posts, and create, update, publish and delete them with a markdown body through the merchant API. Builder pages and block-composed layouts stay dashboard-side.

Good to know:

• Markdown body only; block-built posts and builder pages cannot be written through the merchant API.

• Routes: POST api/v1/merchant/posts

• Scopes: merchant-posts-read, merchant-posts-detail, merchant-posts-create, merchant-posts-update, merchant-posts-delete

Reviews

Product reviews: import, read, reply and moderate

Available

An app can import product reviews and read back the ones it imported. With merchant-product_reviews-read it reads every review of the store in any moderation state, the reviewer shown as first name and last initial. With merchant-product_reviews-respond it publishes the store’s public reply, and with merchant-product_reviews-moderate it approves, hides or holds a review, which moves the product rating at once. Queek sends its own review request two days after delivery unless the store has switched review requests off; an app that sends its own can use the orders/fulfilled webhook as its trigger, once the merchant has switched Queek’s request off so a shopper is not asked twice.

Good to know:

• Review requests, asking shoppers to review after delivery: Queek sends its own two days after delivery, on unless the store switches it off in its settings. Apps cannot send one through Queek or read that setting. An app that sends its own from its own channel when orders/fulfilled arrives should ask the merchant to switch Queek’s off, or shoppers are asked twice. Request timing, contact permission and duplicate delivery are the app’s to manage.
• Reviews are identified by a UUID, not a short numeric id; the product is its p_id.
• The reviewer is the first name and last initial only: no full name, avatar, email, phone or order.
• A reply is published under the store’s name and replaces the previous one; there is no way to remove a reply.
• Moderating a review changes the public product rating at once and applies to any review of the store, including shopper reviews and other apps’ imports.
• Imported reviews are marked unverified.
• Approved imports affect product ratings and Explore ordering, and appear in the shopper product review list, summary and latest approved reviews.
• Verified-only storefront blocks, store-wide block summaries and testimonials hide imports by default; merchants can opt in with verified_only=0.
• Apps cannot retract an imported review after submission, and cannot edit or delete a review.

Workaround: Ask the merchant to switch Queek’s own review request off, then send review requests from the app’s own channel when the orders/fulfilled webhook arrives, reading the shopper’s contact and consent with the customer scopes. Ask the merchant to enable unverified reviews in the storefront blocks, summaries or testimonials that should show imports.

• Routes: GET api/v1/merchant/reviews, POST api/v1/merchant/reviews/import, GET api/v1/merchant/product-reviews, GET api/v1/merchant/product-reviews/{review}, POST api/v1/merchant/product-reviews/{review}/response, PATCH api/v1/merchant/product-reviews/{review}/status
• Scopes: merchant-reviews-read, merchant-reviews-import, merchant-product_reviews-read, merchant-product_reviews-respond, merchant-product_reviews-moderate
• Webhooks: orders/fulfilled

Messaging

Send shopper messages

Not offered by design

Apps send through their own email or SMS provider. Queek provides consent state and events, not a send API.

Queek has no send API for apps; apps send through their own providers. Queek’s own merchant campaigns are a separate product: their SMS sends skip contacts whose SMS consent is unsubscribed but do not require a recorded opt-in.

Good to know:

• Queek stores email unsubscribe and SMS consent states, and has no WhatsApp consent state.
• Queek does not ingest STOP replies.
• An import that stores info.marketing_opt_in=false excludes that contact from campaign reachability.

Workaround: Send through an app-owned provider. Read Queek’s campaign audience and channel consent state, report consent and suppression changes through the consent endpoints, and handle STOP replies with the provider.

• Routes: GET api/v1/merchant/customers, POST api/v1/merchant/customers/{customer}/email-marketing-consent, POST api/v1/merchant/customers/{customer}/sms-marketing-consent
• Scopes: merchant-customers-read, merchant-customers-contact-read, merchant-customers-consent-update, merchant-customers-sms-consent-update
• Webhooks: customers_email_marketing_consent/update, customers_marketing_consent/update

Conversations

Conversation and message API for apps

Available

Installed apps can list and read the store's WhatsApp, Instagram and Telegram conversations and messages, mark a conversation read, reply to a shopper on the store's own line, and subscribe to conversation_messages/create to be told when a shopper writes. The shopper's name and channel handle are masked unless the app also holds the customer contact grant.

Good to know:

• conversation_messages/create fires once for each message a shopper writes, with the conversation id, the channel and the message. It needs the conversations read grant, and the message text can contain contact details. The assistant's and the team's replies do not fire it, and there is no topic for a conversation that changes mode or closes. Delivery is at least once, a message is reported within a few minutes of being stored, and an app added later catches up by listing conversations.
• Message text is written by shoppers and can contain contact details; only the shopper's name and channel handle are masked.
• A reply is text, an image or a product card: no buttons, voice, files or templates. It needs an Idempotency-Key, and on WhatsApp and Instagram it is refused 24 hours after the shopper's last message. Each installation may send 20 replies a minute and 1,000 a day.
• A reply pauses the store's AI on that conversation for the store's takeover window. Apps cannot switch between AI and team, assign or close a conversation, or start a conversation with a shopper.
• The store needs a plan that includes the messaging inbox, and a version that declares the read or reply scope goes through review before release.

Workaround: To change who answers, or to message a shopper who has not written first, use the merchant dashboard inbox.

• Routes: GET api/v1/merchant/conversations, GET api/v1/merchant/conversations/{conversation}, GET api/v1/merchant/conversations/{conversation}/messages, POST api/v1/merchant/conversations/{conversation}/mark-read, POST api/v1/merchant/conversations/{conversation}/messages
• Scopes: merchant-conversations-read, merchant-conversations-update, merchant-conversations-reply
• Webhooks: conversation_messages/create