What Actually Belongs In A Shopify Function

When Does A Rule Belong In A Shopify Function?

Put a rule in a Function when it decides something Shopify already asks about, and when it can reach that decision inside the limits.

Functions do not run when you call them. Shopify's documentation is explicit that Functions are never invoked directly by URL or otherwise, and that Shopify invokes them as needed within the customer journey. You are not writing a service. You are supplying a decision that Shopify asks for at a specific moment.

That framing settles most scoping arguments. If the logic is a decision Shopify already needs, at a moment Shopify already asks, it belongs in a Function. If it is a process that has to run on its own schedule, it does not.

What Functions Replaced

Worth stating plainly because the transition is finished, and in my experience not every team has noticed.

Shopify's documentation states that as of 30 June 2026, Shopify Scripts has been deprecated, and any Scripts still published on a store have been deactivated and no longer work. The instruction is to transition to Shopify Functions to recreate those customisations.

Shopify describes the WebAssembly platform behind Functions as offering better performance than Scripts, executing code in under 5 milliseconds.

If you had a Script doing tiered pricing or a shipping rule, it stopped on that date. Whatever is handling that rule now, it is not the Script. I have written separately about What Already Broke In Checkout, because the Scripts date is frequently confused with the checkout page deadlines and they are separate changes.

The Nine Function APIs

On version 2026-07, the Function APIs reference lists these.

1. Cart Transform, which modifies cart line items.
2. Discount, which creates custom discount types for cart lines and delivery.
3. Fulfillment Constraints, which manages fulfillment group restrictions.
4. Order Routing Location Rule, which directs order fulfilment to specific locations.
5. Delivery Customization, which customises available delivery methods.
6. Payment Customization, which modifies payment method availability.
7. Cart and Checkout Validation, which validates cart contents before purchase.
8. Pickup Point Delivery Option Generator, which generates pickup location options.
9. Local Pickup Delivery Option Generator, which creates local pickup options.

Two of those carry a warning worth heeding. The Pickup Point and Local Pickup delivery option generators are both marked unstable in the reference. My reading is that unstable means do not put a launch date against it, because an unstable API can change without the notice a stable one gets.

Notice what is not on the list. None of the nine covers changing how a page looks or adding a field to checkout. Shopify's developer changelog describes checkout extensibility as a separate set of pieces for that: checkout UI extensions and Functions for new functionality, the Checkout Branding API for styling, and Pixels for event tracking. More in Checkout Extensibility.

The Limits Are The Design Constraint

This is the section I wish more scoping conversations started with. All of these are published on the Function APIs reference at version 2026-07.

Fixed limits:

1. Compiled binary size, 256 kB.
2. Runtime linear memory, 10,000 kB.
3. Runtime stack memory, 512 kB.
4. Logs written, 1 kB, truncated beyond that.

Dynamic limits, stated for carts up to 200 line items:

1. Execution instruction count, 11 million instructions.
2. Function input, 128 kB.
3. Function output, 20 kB.

They are called dynamic because they move. Shopify states that for carts with more than 200 line items these values scale proportionally, so a larger cart is given a larger budget rather than being cut off at the 200 line figure. That is worth knowing before you design around the numbers, and it is also the reason the shape of your logic matters more than the size of the cart. Proportional scaling is linear in the line count. Logic that compares lines against each other is not.

And on the input query itself:

1. Maximum query size, 3000 bytes, excluding comments.
2. Metafield values, 10,000 bytes maximum.
3. List arguments, 100 elements maximum.
4. Maximum query cost, 30.

Read those as a specification rather than as trivia. A 1 kB log allowance tells you that debugging a Function in production is not going to be done by logging your way through it. A 3000 byte input query tells you that you cannot simply ask for everything about the cart and sort it out in code. A 100 element cap on list arguments is a real ceiling if you were planning to pass in a long list of eligible product ids.

The one that catches people is the instruction count. 11 million instructions sounds generous until the logic is quadratic in the number of line items, at which point a cart that is fine in testing is not fine on a trade order.

Why Rust, And When It Matters

Shopify provides function templates and client libraries for Rust and JavaScript, and its own documentation strongly recommends Rust as the most performant language choice, to avoid your function failing with large carts.

That is not a style preference and it is worth reading closely. The named failure mode is the function failing, and the named trigger is a large cart.

My own view is that this makes language choice a commercial decision rather than a developer preference. If your average order is three line items and always will be, JavaScript is likely fine and the team you already have can maintain it. If you sell to trade, run wholesale, or have any customer who orders sixty lines at a time, the limits and the language recommendation are part of the requirement, not an implementation detail.

The honest version of that conversation is to ask what the largest realistic cart looks like, then design for that rather than for the median.

What Does Not Belong In A Function

Working from the documented behaviour rather than from opinion, three categories come out clearly.

Anything that needs to run on its own schedule. Functions are invoked by Shopify within the customer journey, not by you. A nightly reprice, a stock sync, a report is not a Function.

Anything that needs to present an interface. The Function APIs cover decisions, not presentation. Adding a field, changing wording or restyling checkout is the checkout extensibility surface.

Anything that cannot answer within the limits. Those figures are stated for carts of up to 200 line items: 128 kB of input, 20 kB of output, 11 million instructions. If the decision cannot be reached inside them on your realistic largest cart, the Function is the wrong home and the answer needs to be precomputed elsewhere and handed in.

That last one is the useful reframe. Often a rule that will not fit can be made to fit by moving the expensive part out. Work out the eligibility in advance, store the result where the Function can read it cheaply, and let the Function do the small decision it was designed for.

Example: Tiered Trade Pricing In A Discount Function

This is a constructed example, not a client engagement. It is assembled from the documented limits to show how they bite.

A merchant sells components to both retail and trade. Trade customers get tiered pricing that depends on total quantity across a product family, not per line. Retail customers get none of it. Orders from trade run to eighty or ninety lines.

The rule is a natural Discount Function. It decides something Shopify asks about, at the moment Shopify asks.

The limits still shape it. Grouping eighty lines into families and computing a tier per family, naively, means comparing lines against each other. Written carelessly that grows with the square of the line count, while the instruction budget only scales in proportion to it.

There are two workable designs. Precompute the family and the tier boundaries into metafields, so the Function reads a value per line and applies it, staying close to linear. Or keep the grouping in the Function but write it in Rust, given Shopify's own recommendation for large carts.

The decision between them is not really technical. It is about who maintains it afterwards. Metafields plus a simple Function is easier for a small team to hold. Rust is faster but narrows the pool of people who can safely change it later.

That trade off is my judgement, not a Shopify recommendation. The limits are documented; how you spend your budget against them is a design choice.

Signs Your Store Needs A Shopify Function

Five signals. Any two and it is worth scoping properly.

1. You had a Shopify Script and nobody has confirmed what replaced it since 30 June 2026.
2. Your pricing, shipping or payment rules currently live in theme code.
3. You are being quoted for an app to do something that is a decision rather than a feature.
4. Your largest realistic cart is very different from your average one.
5. A rule works in testing and fails intermittently on big orders.

Signal five is the one I would treat as urgent, because in my experience it tends to arrive as a support ticket rather than as a suspicion.

If any of those apply, you can Request The Free Shopify Store Audit.

Common Questions About Shopify Functions

What Are Shopify Functions?

Custom backend logic that runs inside Shopify rather than on your own infrastructure. Shopify invokes a Function as needed within the customer journey, never directly by URL. On version 2026-07 there are nine Function APIs, covering discounts, delivery, payment, cart transforms, validation, order routing and fulfilment constraints.

Did Shopify Functions Replace Shopify Scripts?

Yes. Shopify states that as of 30 June 2026 Shopify Scripts has been deprecated, and any Scripts still published on a store have been deactivated and no longer work. Its documentation directs merchants to transition to Shopify Functions to recreate those customisations.

How Fast Are Shopify Functions?

Shopify describes the WebAssembly platform behind Functions as offering better performance than Shopify Scripts, and executing code in under 5 milliseconds. Separately, version 2026-07 documents an execution budget of 11 million instructions for carts of up to 200 line items.

What Language Should A Shopify Function Be Written In?

Functions must compile to WebAssembly. Shopify provides templates and client libraries for Rust and JavaScript, and strongly recommends Rust as the most performant choice, to avoid your function failing with large carts. If you sell to trade or handle long orders, treat that as part of the requirement.

What Are The Shopify Functions Limits?

On version 2026-07: a compiled binary of 256 kB, runtime linear memory of 10,000 kB, stack memory of 512 kB and 1 kB of logs. For carts up to 200 line items, 11 million instructions, 128 kB of input and 20 kB of output. Input queries are capped at 3000 bytes.

Part of The Shopify Development Guide. See also What Already Broke In Checkout, What Is Actually Worth Optimising On A Shopify Store, Building Complex Shopify Apps and Migration And Replatforming.