Launch checklist

Use merchant-approved test products and photos. The examples on this site do not call a live Antla endpoint.

Connection and catalog

• The SDK script, API base URL, and key come from the same installation.
• Headless SDK or Headless API matches what this app needs. See Choose SDK or API.
• A missing, old, or disconnected key fails as 401.
• If SDK is connected, a valid key loads /context. If API-only, /context returns 403 SDK_NOT_CONFIGURED and other routes still authenticate.
• The public Storefront token can read product tags, variants, availability, and images. Skip this row for API-only apps that do not call /context.
• The product is published to the intended storefront when using the SDK.
• The product has a real Antla Funnel assignment and a usable image.
• Multiple Funnel candidates resolve in the intended order.
• Missing tags and unpublished products produce a useful UI.
• More than 100 variants are handled if your catalog needs them.

SDK storefront

• The script loads once; a delayed/failed load is handled.
• Product and variant attributes stay synchronized after client navigation.
• Unmounting or closing the view does not trigger duplicate generation.
• Sold-out variants do not produce an inappropriate purchase flow.
• Launcher overrides and merchant settings render correctly.
• No integration depends on undocumented theme events or private SDK methods.
• Existing and newly created carts appear in the actual storefront cart.
• Cart, checkout and close result actions behave as expected.

Photos

• Empty, oversized, unsupported, corrupted and incorrectly oriented photos are handled.
• iOS/Android image formats work on the real browser or native path.
• The signed PUT uses raw bytes and the matching MIME type, without the SDK key.
• Expired upload targets can be replaced.
• A photo URL inaccessible to the worker results in useful failure handling.
• Photo URLs and image data are absent from broad logs/analytics.

Identity and consent

• The visitor ID persists only within the intended merchant/environment.
• Null returned IDs do not erase a saved identity.
• Email disabled, optional, required and already-registered cases work.
• EMAIL_REQUIRED can recover with email input.
• Per-user limit and email limit show different messages.
• Consent true, false and absent retain their distinct meaning.
• Shared IPs, backend proxies, shared devices and account switching have been tested.
• Generation-linked email tracking receives customerEmail when intended.

Generation lifecycle

• The success response’s job ID is persisted before polling.
• Duplicate clicks cannot submit parallel jobs accidentally.
• PROCESSING to SUCCESS/PENDING to SUCCESS/READY works.
• PROCESSING to ERROR works.
• Temporary preview then storage failure works.
• Legacy final success without storageStatus works.
• HTTP 200 with job ERROR is treated as failure.
• Malformed or unknown responses are not treated as success.
• Lost POST responses and 5xx do not trigger blind resubmission.
• A timed-out UI can resume an already-known job.
• GET retries honor a deadline, abort, and Retry-After.

Partner and mobile delivery

• Merchant A cannot be mapped to merchant B’s configuration in your app.
• Your backend authorizes user access before exposing stored job IDs/results.
• Aggregate polling fits the actual shared-IP limits.
• App background, foreground, network switch, and app restart are handled.
• WebView camera and file access, denied permissions, and checkout navigation work.
• The app can refresh environment and key configuration after rotation.
• The selected native upload path uses real bytes, not a local URI string.

Production

• Production script URL, API URL, and key come from the merchant’s Antla installation.
• Current store credits cover a controlled real generation.
• The full purchase path works, not only a successful image.

The example clients are tested against mocked HTTP responses. Run a real generation on the merchant’s installation before launch.