App review and distribution
Which apps and updates Queek reviews, what you submit (including a screencast), the automated checks, how review works, and what happens after approval.
Every app goes through review before it is listed publicly in the Queek app store. When you later ship an update that adds a sensitive capability, that update is reviewed again. This page covers what you submit, what the screencast must show, the checks that run before a person looks at your submission, and what happens after approval.
The short version
Submit a version with a screencast link, test-store instructions and contacts. Queek runs automated checks first. A reviewer then approves it or sends it back with reasons. Reviewers will not approve a listing without the screencast.
Who is reviewed and when
| You are shipping | Review |
|---|---|
| An app for its first public listing | Always reviewed. |
| An update to a listed app that adds a sensitive capability (below) | Reviewed again. The previous version stays live while the update is in review. |
| An update to a listed app that adds none of them | Released without review. |
An app registered with distribution = "development" in its manifest | No review. It is not listed in the app store. The distribution is set when the app is registered: editing it later does not turn a registered public app into a development app, so start a separate app for development (see Develop against a development app). |
Review is triggered by what an update adds compared with the version that is currently live.
Removing a capability never needs review, and moving a scope between scopes and
optional_scopes is not an addition.
The sensitive capabilities are a fixed list. Anything not named here does not trigger a re-review.
| Area | What it covers |
|---|---|
| Customer data | Scopes that read, create, update or delete customer records, read customer contact details, or change a customer's marketing or SMS consent. |
| Payments | Scopes that read or update an order's payment, or read payout batches. Also a payment provider declaration that is new or widened (a new provider, extra hosts, paths or currencies, refunds switched on, a changed webhook scheme or added credential fields). |
| Shopper-facing content | Scopes that import product reviews, upload media, or create, update or delete posts. |
| Checkout | The scope that lets an app write checkout requirements to products. |
Scope names are listed in Merchant API scopes.
What you submit
You submit one version at a time, from the dashboard or with queek app submit (see
Build an app, step 7). The submission form asks
for:
| What | API field | Notes |
|---|---|---|
| Screencast link | screencast_url | Required. An https link to a video. See What the screencast must show. |
| Test instructions | test_instructions | Required, up to 5,000 characters. How a reviewer installs and exercises the app on a test store. |
| Contact email | contact_email | Required. Review decisions are also emailed here. |
| Emergency contact | emergency_contact | Required: an email, and optionally a phone number. |
| Acknowledged warnings | acknowledged_warnings | Any warning from the automated checks that you choose to submit with. |
| Data-handling commitments | attestation | Required when the version adds a sensitive capability from the list above. See below. |
Test store only, never production credentials
Put any login or API credentials a reviewer needs inside the test instructions, for a test store and your own test accounts only. Never include production credentials. Reviewers can read the test instructions.
Listing details come from your manifest (mostly the [listing] table), not the form: name, a
description of at least 80 characters, an icon or logo, a privacy policy URL, a support URL and a
category. The automated checks fail the submission if any is missing, and the starter's one-line
placeholder description is too short. See the manifest reference.
Data-handling commitments. When a version adds a sensitive capability, you confirm all four of these. Each is recorded with your account and the time:
- Encrypt Merchant Data at rest and in transit.
- Delete store data on uninstall or request.
- Limit staff access to what they need.
- Keep an incident-response process and tell affected Merchants and Queek without undue delay.
If the Developer Terms have been updated since you last accepted them, you accept the current version before you can submit.
What the screencast must show
Record a screencast that shows how the app works and everything it does. A merchant-facing walkthrough from a fresh test store is the goal: a reviewer should not have to guess what the app does or where to find it.
Show, in this order:
- Install and consent. Installing the app from a test store and the permissions the merchant is asked to grant.
- Set-up. Everything a merchant does after install to get the app working: settings, connecting accounts, first-run steps.
- Every feature a merchant can use. Each page, block, action and automation the app offers, working on real test data.
- What the app reads and writes in the store. Which products, orders, customers or other data the app reads, and what it creates or changes, so the reviewer can match it to the scopes you request.
- Uninstall. Removing the app, and what happens to the merchant's data afterwards.
Narrate or caption it so it can be followed without guessing. An unlisted video link is fine; make sure it opens without signing in. Use a test store: do not show production data or credentials on screen.
Keep the screencast current. Each version that goes to review needs a link that matches that version, so record it again when an update changes what the app does or what it asks for.
Automated checks before a reviewer sees it
When you submit, Queek runs these checks against the version. A failed blocking check stops the submission. A failed warning lets you submit once you acknowledge it.
| Check | Kind | What it verifies |
|---|---|---|
| Listing complete | Blocking | The manifest has a name, a description of at least 80 characters, an icon or logo URL, a privacy policy URL, a support URL and a category. |
| Installed on a test store | Blocking | This version was installed on one of your test stores and opened at least once. Uninstalling it afterwards does not undo this. |
| App responds and verifies signatures | Blocking | Your install, uninstall and (if set) webhook URLs are public https addresses that answer. Your install URL returns a success status to a correctly signed request from Queek and rejects a request with a forged signature with a 4xx status. |
| Embedded page allows the Queek dashboard | Warning | If the app has an embedded page, it sends a Content-Security-Policy header with a frame-ancestors rule. |
| Demo store link | Warning | If the app adds storefront blocks or an embedded page, the manifest carries a demo URL (demo_url) so merchants can try it. |
| Demo link points to your test store | Blocking | If a demo URL is set, it points at one of your own test stores. |
Things worth knowing about how the checks run:
- Queek only contacts the hosts in your own manifest, over
https, and does not follow redirects: a redirect counts as the answer. Probes identify themselves with the user agentQueek-ReviewProbe/1.0and anX-Queek-Probe: reviewheader, and wait up to 5 seconds. - Results are saved with the version and reused for up to 24 hours, unless the version changes. Results older than 24 hours are re-run before you can submit.
- Each message says what failed and what to do about it, so you can fix and run the checks again before you submit.
The review
Submit
Queek runs the checks, then records your submission and puts the version in review. Your version is frozen while it is in review. To change something, withdraw it, or deploy a new version.
A reviewer looks at it
The reviewer sees your checks, test instructions, screencast, contacts and data-handling commitments, with the version's manifest next to the one that is live. Only one version of an app can be in review at a time: submitting a second while one is pending is refused.
Approved or sent back
You are notified in the dashboard and by email, and the decision is also emailed to the contact email on the submission.
- Approved. The version goes live. See After approval.
- Action required. The version is rejected with one or more reasons (listing, functionality, security or policy) and a written note. The review thread opens with the decision and what to do next.
Reply, fix and resubmit
Once the reviewer has posted a decision you can reply on the review thread if something is unclear, and the reviewer answers there. After a rejection, address the points, deploy a new version and submit it.
Withdraw. You can withdraw a version that is in review. It returns to development with the note "Withdrawn by developer", and you can submit again.
Limits. Each developer account can submit or withdraw up to 5 times per day, and the two share that allowance. Replies on a review thread have their own limit of 20 per hour and do not count against it.
After approval
The version is live and the app is listed in the Queek app store. On an app that was already listed, installs keep running the previous version until the update is approved, and the listing then moves to the new one.
Every store can install apps today. There is no plan restriction on installing.
Pricing
Apps are free to install today. Paid apps are not available yet; they will come later.
Deprecations and changes
- Nine months' notice. When something in the public API is deprecated or retired, Queek
announces it in the Changelog and on responses, using the
Deprecation,SunsetandLinkheaders. There are at least nine months between the announcement and the date it stops working. The headers are explained in Versioning and errors. - No dated roadmap. Queek does not publish dates for upcoming capabilities. What is not yet available is listed on the capabilities catalogue without dates, and changes to capabilities are announced in the Changelog. See Stability and status.
Next steps
Build an app
The submit step, with the CLI command.
Manifest
The listing fields the checks look for.
Stability and status
What the capability labels mean and how changes are announced.
Versioning and errors
How retirements are announced on responses.
Changelog
Every change to the APIs, newest first.
Support
Where to ask and what to include.
Customer privacy topics
How an app learns that a merchant asked for a customer's data or for their personal data to be erased, what the payload carries, and what your app must do.
AI toolkit
Agent skills that give a coding agent accurate, source-checked knowledge of the Queek app platform. Install them with one command.