Testing your integration

Quiqqy has one API. There is no sandbox host, no test credential prefix and no second set of endpoints — you develop, certify and run against the same base URLs listed in the platform overview.

What changes between building and launching is not the API. It is whether merchants can find your app.

Your app works before it is published

An app you create in the console starts in draft. A draft app can already do everything a published app can:

Its client_id / client_secret are live from the moment you create them.
POST /pos/signup_url returns a real consent URL.
A merchant who opens that URL and consents produces a real token.
Your webhooks fire, your menu pushes, your orders flow.

Nothing about the request path changes when your app is later published — same host, same credentials, same payloads — so there is no “switch to production” step to get wrong.

What publishing changes is discovery: only a published or beta app is listed in the merchant app catalogue, where merchants browse and install. A draft app is invisible there, so the only merchants who can reach it are the ones you send the consent URL to yourself.

Start in the order sandbox

Before onboarding anything, use the order sandbox. It gives your app a throwaway store, seeded with a menu that covers every shape your parser has to survive, and lets you place a test order from any marketplace Quiqqy integrates — then watch your webhook go out and your calls come back in one timeline.

That store belongs to Quiqqy, so nothing you do there creates a merchant account, emails a merchant or charges anything. It is the cheapest place to get the order round trip right, and the caution above does not apply to it.

It does not replace the section below. A reviewer replays the real consent and onboarding flow, so you still have to exercise it yourself: the sandbox covers the order lifecycle, not onboarding.

Making a store to test against

Run the same onboarding flow a merchant would, and play the merchant yourself:

Call POST /pos/signup_url with a location_id, a store name and an email address you control. Use an address on your own domain — the account created is a real merchant account and Quiqqy emails it.
Open the returned signup_url in a browser yourself, create the merchant account and consent to your app. You now hold a token for a store you own.
Complete integrate-store, push a menu, and keep the webhook_secret from the response server-side.
Order from that store’s storefront to produce a real order.created webhook, and drive it through the lifecycle from your side.

The whole path is documented in Store onboarding. Certifying against a store you own is deliberate: it is the exact flow a reviewer replays, so exercising it early is what makes review short.

What to exercise before you submit

Beyond the happy path, the go-live checklist expects you to have driven each of these at least once against your own store:

A denial with each structured reason, including ITEM_OUT_OF_STOCK with items[].
A webhook with a deliberately bad signature — and your endpoint rejecting it.
A duplicate delivery id, to prove dedupe.
A token refresh, and an auth.consent_revoked handled by stopping sync rather than retrying.
The 202 async menu path polled to completion.

Errors that are about distribution, not your code

Three 403s relate to your app’s state rather than the request:

Error	Meaning
`app_install_revoked`	The merchant uninstalled your app. Stop syncing and ask them to reinstall — do not retry in a loop.
`app_suspended`	Quiqqy suspended the app platform-side. Contact developer support.
`app_not_available`	The app was deactivated or deleted.

None of these is returned because an app is a draft, in review, or unpublished. Those states complete the flow normally.