> ## Documentation Index
> Fetch the complete documentation index at: https://docs.launchmystore.io/llms.txt
> Use this file to discover all available pages before exploring further.
# App Types & Tiers
> Public, private, and first-party app types — and the four pricing tiers
# 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`.
| Type | Marketplace visible | Installable by | Use case |
| ------------- | ------------------- | -------------------------------------------------------------- | --------------------------------------------------------------- |
| `public` | Yes | Any merchant from the marketplace | Third-party apps distributed to the LaunchMyStore community. |
| `private` | No | Only stores explicitly whitelisted by the developer | Custom integrations built for a single merchant or small group. |
| `first-party` | No (special card) | Any merchant — surfaced through curated lists by LaunchMyStore | Apps published by LaunchMyStore or strategic partners. |
There is **no** "custom" app type. Some marketplace UIs use the
word "custom" colloquially for `private` apps that were built for a
specific merchant; the underlying enum value is `private`.
### `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.
* Install URL is generated per-merchant by the developer dashboard
("Add to store" button against a whitelisted shop).
* 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 a single store (custom integrations).
* Multi-store deployments where the same code runs across a handful
of related shops (e.g. a brand operating three regional storefronts).
* Internal tooling that wraps the LaunchMyStore API for an
organization.
Private apps still need OAuth scopes declared in `app.json` —
merchants must authorize them just like a public app. The only
difference is discoverability.
### `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
Choose `private`. Faster to ship, no review queue, full control
over which shops install it.
Choose `public`. Submit through the marketplace review flow once;
every approved merchant can install themselves.
`first-party` is granted by LaunchMyStore. You don't pick this
yourself.
## 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`.
| Tier | API rate limit (req/sec) | Notes |
| ------------ | ------------------------ | ------------------------------------------------------ |
| `free` | 20 | For hobby/test apps and developer dev stores. |
| `basic` | 40 | Default for newly-published apps. |
| `pro` | 100 | Production apps with batch sync or background workers. |
| `enterprise` | 500 | High-volume integrations, ERP/data-warehouse syncs. |
See [API Rate Limits](/api-reference/rate-limits) for the full
sliding-window rate-limit spec and the `X-RateLimit-*` response
headers.
### What each tier unlocks
20 req/sec to `/api/v1/`. Suited to dev stores and internal
prototypes. Webhooks count zero against the rate cap — design
around webhooks where possible.
40 req/sec. Default for new public apps. Bulk endpoints
(metafields, products) work just fine at this tier for typical
sync workloads.
100 req/sec. Recommended for apps with high-frequency polling or
backfill workers. Comes with access to extended diagnostics in the
developer dashboard (function execution timings, webhook delivery
breakdowns).
500 req/sec. For ERP integrations and data-warehouse syncs.
Requires sales/partnership approval — contact LaunchMyStore
support.
### 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:
| Type | Tier | Example |
| ------------- | ------------ | ------------------------------------------------------------------------- |
| `public` | `free` | A reviews widget app where the storefront does almost no API work. |
| `public` | `basic` | A typical SaaS app at the default tier. |
| `public` | `pro` | A high-traffic analytics app polling the orders API every minute. |
| `private` | `enterprise` | A custom ERP bridge for one large merchant ingesting orders in real time. |
| `private` | `basic` | A boutique brand's internal admin tool used by store staff. |
| `first-party` | `pro` | A LaunchMyStore-built operations dashboard. |
## Where they are set
| Property | Where set |
| -------- | --------------------------------------------------------------------------------------------- |
| `type` | At app creation in the developer dashboard. `first-party` is only set by LaunchMyStore staff. |
| `tier` | App settings page in the developer dashboard, or via support for `enterprise`. |
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](/getting-started/app-lifecycle) 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](/functions/active-limits)
(independent of tier).
## See also
Manifest fields that depend on app type (e.g. `permissions`).
Tier-based sliding-window limits and best practices.
Install, update, uninstall flow shared by all types.
What a `public` app needs to pass marketplace review.