October 6, 2026 · Ahmed · More by Ahmed
Shopify Functions: 5 to 25 Per API, Limits Unchanged
Shopify raised the active-function limit per API from 5 to 25. The per-execution resource ceiling didn't move — here's what that combination actually changes.
A changelog entry from May 21, 2025 raised the number of active Shopify Functions allowed per Function API from 5 to 25. Read on its own, that's a quota bump. Read alongside Shopify's Function APIs reference — which documents a fixed checkout execution order and a resource ceiling that applies per function execution, not per API — it's a real architecture decision for anyone building payment customizations, delivery customizations, fulfillment constraints, or cart/checkout validations.
What actually changed
Shopify's changelog states it directly: "Shopify Functions now supports up to 25 active functions per Function API, increased from the previous limit of 5. This allows developers to split complex or unrelated logic into smaller, dedicated functions rather than combining everything together." It applies to payment customizations, delivery customizations, cart and checkout validations, and fulfillment constraints.
What the changelog doesn't say, and what the Function APIs reference confirms separately, is that nothing about a single function's resource budget moved. The fixed limits — 256 kB compiled binary size, 10,000 kB runtime linear memory, 512 kB runtime stack memory, and 1 kB of (truncated) logs — apply to every function execution regardless of how many functions are active on the API. The dynamic limits, which scale with cart size, are the same story: for carts up to 200 line items, a single execution gets up to 11 million instructions, 128 kB of input, and 20 kB of output. Shopify is explicit that the output ceiling "doesn't support bulk price transformations across all line items" — that's still a job for discount functions, B2B catalogs, or targeting specific products, not something the higher function count changes.
The real tradeoff: merge logic, or split it
Under a limit of 5, teams with several unrelated business rules — say, a loyalty-tier shipping discount, a B2B minimum-order validation, and a fraud-risk cart check — had a real incentive to merge them into fewer functions just to stay under the cap. That's a bad trade: each merged function still carries the same fixed 256 kB binary ceiling and the same 11-million-instruction budget, so cramming three unrelated rules into one execution means all three share one resource envelope instead of each getting its own. A failure or a slow path in one rule can burn budget that another rule inside the same function needed.
At 25 active functions per API, that pressure mostly disappears. Each business rule can be its own independently deployed function, each with its own full 256 kB / 10,000 kB / 512 kB / 11-million-instruction allowance, each one simpler to reason about and redeploy without touching the others. The input query itself still has to stay under a maximum calculated cost of 30 — reading a metafield costs 3, a hasTags check costs 3, other leaf fields cost 1 — so a smaller, focused function is also easier to keep under that query-cost ceiling than one function trying to read everything every other merged rule also needed.
Why execution order still matters more than the count
Shopify's Function APIs reference documents a fixed checkout sequence: cart lines, then Cart Transform, then cart line discounts, then Discount, then fulfillment groups, Fulfillment Constraints, Order Routing, delivery methods and option generators, Delivery Customization, delivery discounts, Discount again, payment methods, Payment Customization, Verification, and finally Cart and Checkout Validation. The docs are explicit about the consequence: "each step builds on the data from previous steps, so that a cart validation function can't run until after discount calculations are complete."
That ordering doesn't change with 25 functions instead of 5 — splitting one merged function into five smaller ones at the validation stage doesn't move any of them earlier in the sequence, and none of them can see data that a later stage hasn't produced yet. More functions means more independent units to design, test, and deploy at each stage of that fixed pipeline — not more control over where in the pipeline they run, and not a bigger budget for any single one of them.