Compliance & Preliminary Steps

Work through this before you submit. Everything in the first section is machine -enforced — failing any of it means your submission is rejected at the door, not by a reviewer.

Blocking — checked automatically

  • [ ] App URL is set and is https. It is required for an external-hosted app.
  • [ ] Every URL is https and publicly resolvable. App URL, Redirect URL, Webhooks URL and any logo URL. No localhost, no private ranges, no IP literals in numeric form. See Automated Checks.
  • [ ] Version is valid semver — 1.0.0, not v1 or 1.0.
  • [ ] Name ≤ 120 characters, description ≤ 5000.
  • [ ] Every permission is on the allowlist and is one you actually use.
  • [ ] Every subscribed event is on the allowlist — there are 9, and subscription/billing events are not among them.
  • [ ] For themes: npm run validate passes and theme.config.json has name, slug, version, author with a slug that is not default, grid, manfare or general.

Practical — checked by a human, or by your merchants

  • [ ] Your service is actually running at the URLs you submitted, and stays up through review. There is no staging mode; the reviewer sees what you deployed.
  • [ ] The launch-code exchange works end to end. Open the app from a demo shop and confirm you get an access token and can call the Merchant API. See Building Your App.
  • [ ] Your webhook endpoint verifies the HMAC signature and returns quickly. Deliveries are retried 6 times over 24 hours; an endpoint that hangs will hurt you.
  • [ ] Handle app.uninstalled. Access is revoked the moment a merchant uninstalls, and any token you cached stops working on its next call. Clean up your side.
  • [ ] Store the client_secret safely and server-side only. It is shown once. Never put it in browser code.
  • [ ] Description carries the listing. There is no icon, screenshot or media upload for apps — name, category and description are the entire listing.
  • [ ] Scope down. Asking for write_* scopes you do not use is the most common reason a reviewer pushes back.

Data handling

The platform gives you scoped, revocable access to a merchant's shop data. What you do with it off-platform is on you:

  • Store only what your app needs to function.
  • Delete a merchant's data when they uninstall — nothing forces this, because there are no data-erasure webhooks on this platform, but merchants expect it.
  • Keep credentials, tokens and shop data out of logs.

Before every resubmission

Editing an approved app sends it back to pending, so treat each edit as a release:

  • [ ] Bump the version.
  • [ ] Re-check any URL you changed against the https and public-host rules.
  • [ ] Confirm your live deployment matches what you are submitting — the review happens against your running service, not against a snapshot.