Building Apps · marketplace
Building apps on the current platform
App identity, version manifests, supported capabilities, and conservative extension planning.
Building apps on the current platform
Build a server-side integration against the public boundary. Treat every capability by its documented status and design the app to operate with least privilege, bounded failure, and no knowledge of internal topology.
Supported and partial capabilities
| Capability | Status | Contract |
|---|---|---|
| Product-list reads | CURRENT | Public API v1 product fields. |
| Order-summary reads | CURRENT | Public API v1 summary fields. |
| Webhook subscription management | CURRENT | List, create, and disable. |
| OAuth/token infrastructure | PARTIAL | Reviewed consent and token exchange exist; release enablement remains pending. |
| Commerce webhook notifications | PARTIAL | Resource producers and signed delivery are implemented; full private release acceptance is pending. |
Customer, inventory, active discount and store identity reads use the documented field allowlists. Product, discount and order mutations remain PLANNED. Payment-provider mutations, shipping mutations, messaging, AI, automation, embedded UI/theme extensions, and official SDKs are DEFERRED.
App identity and slug
The app is the stable publisher-owned identity. Its slug uses lowercase letters, digits, and hyphens and remains unique. Listing names and descriptions are bilingual. Do not use the app identity to impersonate SaaS or a merchant.
Exact version manifests
Each semantic app version is reviewed independently. Its manifest declares exact redirect URIs, requested scopes, webhook event names, and bilingual release notes. Redirects are exact values, not patterns. Use HTTPS outside controlled local development.
Requested scopes
Request the smallest subset needed by actual current operations. Three registered write scopes currently have no public route. Including one in a manifest does not create an endpoint or authorize private access. New scopes require a new reviewed version and a merchant grant; they are never silently added to an existing installation.
Webhook declarations
A webhook declaration limits which events an app may receive. Use the documented resource event contract, show only reviewed events in merchant consent, and design for retries, expiry and a deleted referenced resource. The current private release gate remains closed.
Lifecycle-aware design
An installation is pinned to one exact published version. Publishing another version does not upgrade it. Design uninstall and downgrade behavior to stop access cleanly, preserve merchant data unless the merchant requested deletion, and never perform destructive surprise actions.