Submit for review

You have an app running on your development store. This is the step that lets other merchants install it.

A version pins the contract, not the code

Submitting creates a version: your hosted URL, the permissions you request, your webhook topics, and your App Store listing. It does not touch your code.

That means:

• Deploying does not need us. Ship on a Friday. Tanqory neither sees your code nor needs to.
• Changing the contract does. A new scope, a new origin, a new webhook topic — those are what merchants agreed to, so those are what get reviewed.

Only one version may await review at a time. Submitting a second while the first is open is refused rather than queued.

Every scope needs a reason

This is the part people are unprepared for. A submission is rejected before it reaches a human if any requested permission has no justification:

Explain why you need orders.edit, customers.view_payment_methods. Reviewers approve scopes, not apps.

Write the reason a merchant would want, not the reason your code has. "To show the order total on the dashboard card" is reviewable. "Needed by the SDK" is not.

See Permissions for the full catalog. Asking for fewer is faster to approve and less likely to be declined at the merchant's install screen — they see the list, not your reasoning.

Preflight runs first

Three machine checks, and they exist because they are the things a reviewer cannot check by hand:

Check	What it means
app-url-reachable	Your origin answers
frame-ancestors	Your CSP admits the Tanqory dashboard
x-frame-options	Nothing older is contradicting it

A warning does not block. A failure does.

The x-frame-options check catches the single most common way an app fails silently: the header has no allow-list form, so SAMEORIGIN overrides your Content-Security-Policy: frame-ancestors in browsers that still read it, and the dashboard shows a blank frame with no error.

Then a person reads it

The substance of a review is scope justification — whether what you asked for matches what you do. The outcome is PUBLISHED or REJECTED.

A rejection always carries a reason. The platform refuses to record one without: "A rejection the developer cannot act on wastes both sides' time." Fix and submit again.

Changing your mind

Withdraw pulls a pending version out of review — it does not remove your app from the marketplace.

• If you already have a live version, the app returns to PUBLISHED and merchants keep running the version they had.
• If you never had one, it returns to DRAFT.

Adding a scope later does not break anyone

When an approved version asks for more than a merchant already granted, their installation moves to PENDING_REAUTH. Your app keeps working on the permissions they agreed to until they agree to the rest.

Handle that state. It is not an error, and it is not rare — it is what happens every time you grow.

The states

State	Belongs to	Means
DRAFT	the app	Created, never submitted. Test-installable on your own development stores.
IN_REVIEW	a version	Submitted. Only one at a time.
PUBLISHED	the app	On the marketplace. Merchants may install.
REJECTED	a version	Turned down, with a reason. Fix and resubmit.
LIVE	an install	A merchant is running it on the scopes they granted.
PENDING_REAUTH	an install	You asked for more than this merchant granted. Still running on the old set.