Skip to main content

​
Function Active Limits

LaunchMyStore caps how many actively-installed apps a single shop can have running per function type. The cap is enforced at install time — if installing your app would push the merchant over the limit for any of the function types it ships, the install fails with HTTP 409.

​
Why the caps exist

Every active function of a given type is dispatched on every cart verification and order placement call. Without an upper bound, a shop could:
  • Compound discounts unbounded — 50 active discount functions all emitting overlapping reductions on the same lines, blowing through the merchant’s margin.
  • Stack payment customizations that rename or hide the same method in conflicting ways, producing UI that flickers as each function’s override fires.
  • Run order validation rules that each adds latency to checkout; ten 500-ms WASM modules add 5 seconds to every checkout submit.
  • Multiply WASM CPU cost for cart-transform pipelines that compete for the same line ids.
The caps are deliberately conservative for the high-impact types (cart_transform, order_validation) and generous for low-cost, additive types (discount).

​
Per-type limits

These caps are defined in FUNCTION_ACTIVE_LIMITS in the backend apps/functions/function-contracts.ts and applied by apps.service.installApp().
Caps apply to active installs only. Uninstalling the app (or its installation being suspended) frees the slot for another app of the same type.

​
What “active install” means

A function counts toward the cap when all of these are true for an app installed on the shop:
  1. The app’s installation row has status = 'active' (not uninstalled, suspended, or pending).
  2. The function entry exists in the installed version’s manifest.
There is no per-function merchant toggle — every function in an active install’s manifest counts. Apps in draft or review status on the developer dashboard don’t count — only published apps installed on a merchant’s shop.

​
Hitting the cap

When a merchant tries to install an app that would push them over the cap for any function type the app contributes, the backend returns:
There is no machine-readable code or details object — the response carries a single human-readable message describing the type, the current count, and the per-shop limit. The merchant admin shows this as an inline error on the marketplace install button: “You’ve reached the limit for this function type. Disable another app first.”

​
Freeing up a slot

Merchants have three ways to free a slot for a competing app:
1

Uninstall a competing app

Removes the app entirely. Slot frees immediately.
2

Ship a version without the function

The cap counts manifest entries on active installs — an app version that drops the function frees that slot without removing the app. (There is no per-function merchant toggle.)
3

Switch to a unified app

If two apps each contribute one cart_transform, the merchant can switch to a single bundled app that performs both transforms in one function — using the cap of 1 just once.

​
Edge cases

An app that contributes a cart_transform AND a discount function consumes one slot from each cap. Installing it requires both caps to have headroom — it’ll fail with 409 even if only one is full.
Uninstalling sets the installation row to inactive; the slot frees immediately. Reinstalling counts the same as a fresh install for cap purposes.
Updating an installed app to a new version that adds a new function type re-checks the cap for that type. If full, the update fails with 409 and the previous version stays active.
Caps apply per shop, including the developer’s own dev shop. A developer testing 10 discount-function variants in one shop must uninstall some between iterations or stay under 25 active installs.
Order-routing rules declared as type fulfillment_location_rule are JSON matchers — not WASM functions. They are only parsed from the manifest today (there is no backend dispatcher yet), so they never execute and don’t count toward any cap. See Order Routing.

​
Designing within the caps

If you’re publishing an app that ships any function, design with the caps in mind:
  • Bundle related logic into one function where possible. One discount function that picks the right rule based on cart contents beats five thin functions each gated on its own condition.
  • Use inputFields so your function dispatches faster and is less likely to be cited by merchants as “the slow one.” See Input fields.
  • Document the cap in your marketplace listing if your app contributes a cart_transform — merchants can have only one such app and need to know before committing.
  • Surface conflicts. If your discount function produces surprising results when another app is also installed, log a warning to the developer dashboard via the test endpoint.

​
See also

Functions Overview

The nine function types and what each one does.

Input fields

Reduce dispatch cost by projecting the input down to only the fields your function reads.

App Manifest

Manifest fields for declaring functions.

App Tiers

Tier-based API rate limits run alongside the function caps.