​

App Types & Tiers

Every app on LaunchMyStore has both a type and a tier. The type controls distribution and marketplace visibility; the tier controls quotas (API rate limits, supported features). They are independent — a private app can be on any tier; a marketplace public app can be on free.

​

App types

The type field on the Apps row identifies the distribution model. The enum has exactly three values: public, private, and first-party.

​

public

The default for marketplace distribution.

• Listed in the marketplace at /marketplace.
• Discoverable via search, category browse, and editorial collections.
• Requires the standard review flow before going live (draft → review → published).
• Subject to the marketplace’s listing requirements: icon, screenshots, long description, privacy policy URL, support email.
• Install metrics (installs, uninstalls, reviews) feed into the marketplace ranking.

Use public when you want any LaunchMyStore merchant to be able to discover and install your app without you preapproving them.

​

private

The most restricted type — invisible to the marketplace.

• Not listed anywhere in the marketplace UI.
• Installable only on the developer’s own store — the store that created the app. There is no whitelist mechanism; any other store attempting to install gets 404 App not found. Install via the Developer Portal’s Install on My Store button.
• Skips the marketplace review queue. Installable by the owning developer’s store immediately in any status (draft/review/ published) and fully usable there — embedded admin, app proxy, OAuth, and theme app blocks all work without marketplace publication. (Publication only matters for public/first-party distribution to other merchants.)
• Useful for:
  • Apps written for your own store (custom integrations).
  • Internal tooling that wraps the LaunchMyStore API for your organization’s store.
  • To run the same code on multiple stores, publish it as a public app (each of your stores then installs it from the marketplace) — private apps cannot be shared across stores.

​

first-party

Apps published by LaunchMyStore itself or strategic partners.

• Surfaced in dedicated cards/collections inside the marketplace UI (e.g. “Apps by LaunchMyStore”, “Recommended for new stores”).
• Bypass the standard public review queue (vetted ahead of time).
• May have access to internal APIs not available to public apps — e.g. surfaces in admin areas that public apps cannot inject into.
• The Apps.type enum stores them as first-party (with the hyphen); do not confuse with firstParty or FIRST_PARTY in code-style contexts.

Developers cannot self-declare first-party — the type is set by LaunchMyStore staff during onboarding.

​

Choosing a type

​

App tiers

The tier field controls the app’s API rate limit and (in some cases) which platform features it has access to. The enum has four values: free, basic, pro, and enterprise. See API Rate Limits for the full sliding-window rate-limit spec and the X-RateLimit-* response headers.

​

What each tier unlocks

​

Choosing a tier

• Start at basic when publishing — this is the default.
• Upgrade to pro when your worker logs 429 responses against your dev store more than once per merchant-day.
• Request enterprise for any integration that needs to ingest hours of historical data in minutes (ERP onboarding, analytics warehouses, replatform migrations).
• Use free for dev stores during development to keep your bills accurate to production.

​

Tier changes propagate within 60 seconds

The rate-limit guard caches tier lookups in-process for 60 seconds. A tier upgrade approved on the dashboard takes up to one minute before your worker sees the higher cap.

​

Type and tier together

The two settings are independent. Examples of valid combinations:

​

Where they are set

Both values are visible on the app’s detail page in the developer dashboard and in the GET /apps/developer API response.

​

Lifecycle interactions

Type and tier do not change the app’s lifecycle — the install/update/uninstall flow is identical for all combinations. Specifically:

• All types use the same OAuth flow for granting scopes.
• All types fire webhooks with the same HMAC-signed wire format.
• All types must declare permissions in app.json.
• All types are subject to function active limits (independent of tier).

​

See also