Stability and status
What the capability status labels mean, how the catalogue is kept accurate, and how changes and deprecations are announced.
This page explains how far you can trust the App capabilities catalogue, and how you find out when something changes.
What the status labels mean
| Label | What it tells you |
|---|---|
| Available | The capability works as the catalogue describes, within any limit shown beside it under Good to know. |
| Partly available | Some of it works. The entry says what is missing, with a workaround where there is one. Design around the gaps. |
| Not yet available | The platform does not offer it to apps today. The workaround page lists a workaround where one exists. |
| Not offered by design | Queek does not offer it on purpose. The entry says why and what to use instead. It is not on the roadmap, so do not wait for it. These are listed at the end of the workaround page. |
A label describes the platform as it is now. Queek publishes no dated roadmap promises: what is not yet available is listed on the workaround page without dates, what is not offered by design is listed there too and is not planned, and changes to capabilities are announced in the Changelog. Do not plan around a capability arriving by a particular time.
How the catalogue is kept accurate
The catalogue is not written by hand. It is generated from the platform's own capability registry each time these docs are built, so a status is read from the platform rather than copied into a page. Almost every row in the registry carries a probe, a check against the platform itself, and the platform's automated test suite evaluates those probes. For those rows a status cannot drift from what the platform does without a test failing. The few rows without a probe are curated by hand.
Do not infer support from an API name, and do not call undocumented endpoints. If a capability is not in the catalogue, treat it as not available.
What stays stable
The platform has a single major version, v1, in the path. Inside it:
- fields and endpoints may be added;
- nothing is removed, renamed, retyped or given a new meaning;
- enum values may be added, and your code must tolerate values it does not know.
A breaking change would ship as v2 beside v1, never in place. The same promise covers webhook payloads, and every webhook delivery states the contract it was built against in X-Queek-Api-Version.
How a deprecation is announced
If something in the public API is ever deprecated or retired, it is announced in the Changelog and on the responses themselves. There are at least nine months between the announcement and the date it stops working:
| Header | Meaning |
|---|---|
Deprecation | RFC 9745: when the endpoint was marked deprecated. |
Sunset | RFC 8594: the date it stops answering. |
Link: rel="deprecation" | Where to read what replaces it. |
Log these headers if you can. They are the earliest warning you will get. The full policy is on Versioning and errors.
For how apps are reviewed and listed, see App review and distribution.
Where changes are recorded
The Changelog records every change to the Storefront API and the Merchant API, newest first, including behaviour that was corrected.
Getting help
Ask in GitHub Discussions, email the developer team, or check the status page when the API misbehaves. Support lists where each goes and what to include so a question can be answered the first time, starting with the request_id from the failing response.
Reference values
Webhook topics, tokens, rate limits, extension and manifest limits, credential endpoints and error codes for Queek apps.
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.