Skip to content

Getting started

This walkthrough takes you from no account to a successful sandbox API call. Everything happens in the developer console except the last step, which you run from your own backend.

You need a work email address you control and a backend that can keep a secret. Client secrets and webhook secrets must never ship in a POS terminal build, a mobile app or browser code.

  1. Sign up at the console with your name, work email and a password. Quiqqy emails you a verification link; the account cannot sign in until you open it.

    Developer accounts are separate from merchant accounts. Using the same email for both is fine — they are different identities in different systems.

  2. Signing in for the first time drops you on the developer application. Tell us who you are and what you intend to build: company name, country, website, a paragraph on the use case, and which products you need — Online Ordering, Hub Ordering, Mercnet Reports, or any combination.

    A Quiqqy reviewer approves or declines, and you are emailed either way. Applications are usually answered within two business days.

  3. Once approved, the console shows the current developer agreement. Read it, tick the acknowledgement box and sign with your full name. The signature is recorded against your account and the agreement version, and the rest of the console unlocks. If a newer agreement version is published later, the console asks you to sign again before you can make further changes.

  4. In Apps → New app, give the app a name and a one-line description. The app is the unit everything else hangs off: credentials, webhooks, store integrations, usage logs and — when you get there — the go-live review.

  5. Open the app’s Credentials tab and create a client credential. You get a client_id and a client_secret:

    Shown once — copy it now
    client_id app_7pk2mv9qx4rt
    client_secret qk_sb_5zkq5vj2rn8pxw3tfm6bd1yh4sc7ae0g

    The secret is hashed the moment it is stored; there is no endpoint that reads it back. If you lose it, rotate the credential and use the new one. While the credential is there, also register at least one Allowed Redirect URI — the OAuth flow in the next step refuses redirect targets that are not on the list.

  6. Sandbox credentials work only against https://sandbox.quiqqy.ai/api/v2. The sandbox is a full copy of the platform with test stores and a test order generator — see Sandbox. Nothing you do there touches a live merchant.

  7. The first real call in any Online Ordering integration is POST /pos/signup_url: it provisions a (test) merchant and store and returns the consent URL the merchant would visit to authorize your app. It authenticates with your client credentials over HTTP Basic — no token needed yet.

    Terminal window
    curl -s https://sandbox.quiqqy.ai/api/v2/pos/signup_url \
    -u "app_7pk2mv9qx4rt:qk_sb_5zkq5vj2rn8pxw3tfm6bd1yh4sc7ae0g" \
    -H 'Content-Type: application/json' \
    -d '{
    "location_id": "LOC-001",
    "store_name": "Main Street Pizza",
    "email": "owner@mainstreetpizza.example",
    "redirect_uri": "https://pos.example.com/quiqqy/callback"
    }'
    200 OK
    {
    "status": "success",
    "signup_url": "https://sandbox.quiqqy.ai/api/v2/oauth2/authorize?client_id=app_7pk2mv9qx4rt&redirect_uri=…&email=…"
    }

    A signup_url in the response means your credentials, environment and redirect URI all line up. In sandbox you can open that URL yourself and play the merchant — the full flow is in Store onboarding.