Skip to main content

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

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.
TypeMarketplace visibleInstallable byUse case
publicYesAny merchant from the marketplaceThird-party apps distributed to the LaunchMyStore community.
privateNoOnly stores explicitly whitelisted by the developerCustom integrations built for a single merchant or small group.
first-partyNo (special card)Any merchant — surfaced through curated lists by LaunchMyStoreApps 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; goes live as soon as the developer publishes a version.
  • 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

1

Built for one merchant?

Choose private. Faster to ship, no review queue, full control over which shops install it.
2

Distributing to multiple unrelated merchants?

Choose public. Submit through the marketplace review flow once; every approved merchant can install themselves.
3

Working with the LaunchMyStore team?

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.
TierAPI rate limit (req/sec)Notes
free20For hobby/test apps and developer dev stores.
basic40Default for newly-published apps.
pro100Production apps with batch sync or background workers.
enterprise500High-volume integrations, ERP/data-warehouse syncs.
See API Rate Limits for the full sliding-window rate-limit spec and the X-RateLimit-* response headers.

​
What each tier unlocks

Free

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.

Basic

40 req/sec. Default for new public apps. Bulk endpoints (metafields, products) work just fine at this tier for typical sync workloads.

Pro

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).

Enterprise

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:
TypeTierExample
publicfreeA reviews widget app where the storefront does almost no API work.
publicbasicA typical SaaS app at the default tier.
publicproA high-traffic analytics app polling the orders API every minute.
privateenterpriseA custom ERP bridge for one large merchant ingesting orders in real time.
privatebasicA boutique brand’s internal admin tool used by store staff.
first-partyproA LaunchMyStore-built operations dashboard.

​
Where they are set

PropertyWhere set
typeAt app creation in the developer dashboard. first-party is only set by LaunchMyStore staff.
tierApp settings page in the developer dashboard, or via support for enterprise.
The values live in the backend Apps table: 
SELECT "appId", handle, name, type, tier, status FROM "Apps" WHERE handle = 'my-app';

​
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

App Manifest

Manifest fields that depend on app type (e.g. permissions).

API Rate Limits

Tier-based sliding-window limits and best practices.

App Lifecycle

Install, update, uninstall flow shared by all types.

App Listing

What a public app needs to pass marketplace review.