Go live

Every new app starts in draft: you can build, test and iterate freely against your own org’s sandbox businesses, but the OAuth flow refuses to connect the app to any real business. Review is what removes that restriction — it’s enforced server-side at both the consent step and the token exchange, not just a console badge.

Review states

DRAFT ──submit──▶ SUBMITTED ──▶ IN_REVIEW ──▶ APPROVED
                                    │
                                    ├──▶ CHANGES_REQUESTED ──resubmit──▶ SUBMITTED
                                    └──▶ REJECTED ──────────resubmit──▶ SUBMITTED

State	Meaning
DRAFT	New app; sandbox-only.
SUBMITTED	Waiting for a reviewer to pick it up.
IN_REVIEW	A reviewer is actively working it.
CHANGES_REQUESTED	Sent back with feedback — visible in the console. Fix and resubmit.
REJECTED	Declined, with feedback. You may resubmit.
APPROVED	Live — the app can connect to any OneBooks business.

DRAFT, CHANGES_REQUESTED and REJECTED can be (re)submitted; SUBMITTED, IN_REVIEW and APPROVED cannot.

Submitting

Only org admins can submit. The console’s submission wizard collects:

• Description — what the integration does and who it’s for.
• App URL — your product’s site.
• Privacy policy URL and Terms URL.
• Support email (support phone optional).
• Demo video URL (optional, but a 3-minute walkthrough of the OAuth connect flow plus your core sync speeds reviews up considerably).
• A self-certification checklist:
  • tested end-to-end against a sandbox business,
  • errors are handled (401 refresh, 429/5xx backoff),
  • client secret and tokens are stored securely.

What reviewers look for

Request only the scopes your description justifies. A “read-only reporting dashboard” asking for fiscal-year:write is the fastest way to CHANGES_REQUESTED.

After approval

Approval unlocks the authorization flow for any business — your onboarding flow can now send real merchants through OAuth consent. Sandboxes keep working as before.

Widening scopes re-gates your app

Editing an approved app’s registered scopes to include any scope not in the reviewed set immediately resets it to CHANGES_REQUESTED: new authorizations against real businesses stop working until you’re re-approved. Narrowing or keeping the set unchanged has no effect. Plan scope additions as a release, not a hotfix.

Note that already-issued tokens and consents are not what review gates — the gate applies to completing new authorizations.

Launch checklist

1. All scopes trimmed to what the integration actually uses.
2. Refresh logic single-flighted; family-burn recovery path tested (Authentication).
3. Webhook signature verification live, test delivery verified (Webhooks).
4. Idempotency keys on every write you might retry (Integration patterns).
5. Review submitted with accurate URLs and support contacts.