# Review & publishing

What we check, how long it takes and how to pass first time.

## Submitting

Submitting freezes a **version**: listing content plus the requested scopes. The app moves to `in_review` and the listing becomes read-only until we respond.

## Statuses

| Status | Meaning |
| --- | --- |
| `draft` | Work in progress, only visible to your organization |
| `in_review` | Submitted, waiting for a reviewer |
| `changes_requested` | Fixable issues — edit and resubmit |
| `rejected` | Not eligible in its current form |
| `published` | Live in the App Store |
| `unpublished` | Hidden from the store, existing installs keep working |

## What reviewers check

1. **Scope hygiene** — every requested scope is justified by the described functionality. Asking for `payments:create` for a reporting app is the most common rejection.
2. **Working install** — the OAuth flow completes against a real redirect URI and the app renders something useful.
3. **Listing accuracy** — screenshots show the actual product, pricing matches what you charge.
4. **Legal pages** — reachable privacy policy and support contact, and a data-handling statement.
5. **Webhook health** — your endpoint answers `2xx` within 10 seconds during the test delivery.
6. **Stability** — no error spikes in your sandbox logs for the submitted version.

## Timing

Reviews are usually answered within 3 business days. Resubmissions after *changes requested* are prioritized.

## Publishing

On approval:

- in **live** mode the one-time publishing fee is charged to your billing method;
- the listing goes public in the App Store;
- merchants can install immediately.

Publishing is blocked while your payout account is `restricted` or `disabled`.

## Updating a published app

Editing a published listing creates a new version in `draft`. The live listing keeps serving until the new version is approved. Adding **new scopes** requires re-consent: existing installations keep the old scopes until the merchant approves the update.