Testing and going live

Review states

An app has one of four states:

Moves: you submit a draft for review. A reviewer approves a submitted app, sends it back to draft with a reason, or suspends it with a reason. A suspended app cannot resubmit itself; a reviewer lifts the suspension. The developer is told every decision, and on a suspension every store with the app installed is told too.

Changing an approved app's scopes or redirect URIs returns it to pending_review. Editing its name or listing does not.

This page describes the states and the rules a reviewer applies in the platform. How long a review takes and what a reviewer checks beyond these rules are not published.

The listing

An app cannot be submitted without a listing. Set it with PATCH /oauth/apps/:id:

{
  "listing": {
    "name_ar": "arabic name",
    "name_en": "Reorder reminders",
    "tagline_ar": "arabic tagline",
    "tagline_en": "Remind customers to reorder.",
    "description_ar": "arabic description",
    "description_en": "What the app does, in plain words.",
    "icon_url": "https://example.com/icon.png",
    "category": "operations"
  }
}

• Names up to 120 characters, taglines up to 160, descriptions up to 4,000. icon_url is optional and must be https.
• category: one of sales, marketing, operations, design, analytics, utilities.
• Submission requires the Arabic name and a category. Stores in Egypt read Arabic first, so write the Arabic listing for real.

Then POST /oauth/apps/:id/submit. Anything but a draft answers oauth_app_not_submittable; a missing listing answers oauth_app_listing_required.

Listing copy is stored with the app. Which screens show it to stores is not covered here: the registry that lists approved apps currently exposes the app's name, scopes and whether it is embedded.

Testing before approval

There is no sandbox and no test mode. The consent flow and token issue are refused for any app that is not approved, so a draft app cannot get a token, not even for your own store.

What you can do before approval:

• Build against the response shapes in the API reference and write tests with recorded or hand-written fixtures. @hekana/apps-sdk takes a custom fetch for exactly this (it is source-only for now; see Getting started).
• Write and test your webhook receiver with a signature check. You can generate a signed body yourself with the algorithm in Webhooks.
• Check your redirect URIs and PKCE code against the rules in Authentication.

After approval you can install the app on a store you own and use POST /webhooks/:id/test and GET /webhooks/:id/deliveries to debug deliveries.

Going live checklist

1. Scopes: only what you call. Every added scope later means a new review.
2. Redirect URIs: final https addresses.
3. Listing complete in Arabic and English.
4. Client secret stored on your server only, never in a repository or a browser.
5. Webhook receiver verifies the signature, deduplicates on id and answers quickly.
6. Retries: POSTs carry an Idempotency-Key, and orders use a stable reference.
7. Uninstall: you delete that store's data when app/uninstalled arrives.
8. Release a version (POST /oauth/apps/:id/versions) so the history starts at your first live build.

Not available

• A sandbox, test stores for apps, or test credentials.
• A published review checklist or review time.
• Documentation of where a third-party app's listing is shown to stores.