What is Code by Zapier?

It is a built-in Zapier action that runs a short snippet of JavaScript or Python as one step inside a Zap. It receives values mapped from earlier steps as inputs and returns values that later steps can use. It exists as an escape hatch for the transformations that Zapier's built-in Formatter and app actions cannot express, and it runs in a sandboxed environment with a short execution timeout.

Can I install npm or pip packages in Code by Zapier?

No, not arbitrarily. The environment is sandboxed and only provides the built-in language features and a limited set of available facilities, including standard ways to make HTTP requests. If your logic genuinely requires a third-party library, that is one of the clearest signals to move it out of the Zap and into a small deployed function that the Zap calls by webhook. Check Zapier's current documentation for exactly what is available, since this changes over time.

Why do my numbers come through as text?

Because Zapier passes all mapped input values into the Code step as strings, regardless of their original type. This is one of the most common sources of confusing behaviour - arithmetic silently concatenates instead of adding, and comparisons behave unexpectedly. Parse every input explicitly at the top of your snippet before using it, and do not rely on implicit type coercion to do the right thing.

How do I make the rest of my Zap run once per item in a list?

Return an array of objects from the Code step instead of a single object. Zapier interprets an array as multiple items and runs the remaining steps once for each one. This fan-out behaviour is one of the genuinely strong reasons to use a Code step, because it is difficult to express any other way in Zapier. Be mindful of task consumption - a list of two hundred items means two hundred runs of every subsequent step.

When should I replace a Code step with a real service?

When any one of these is true: the snippet is longer than about one screen, you want to write a test for it, two or more Zaps need the same logic, it needs an unavailable package, it approaches the execution timeout, or someone other than its author needs to change it. The migration is small - deploy the logic as an HTTP function and replace the Code step with a webhook POST. The Zap keeps its trigger, filters and actions; only the thinking moves out.

Code by Zapier: What It Is, When to Use It, and When to Stop

Code by Zapier is the escape hatch that makes a Zap capable of anything - and the step that quietly turns your automation into undocumented software. Here is what it can actually do, the patterns worth using, and the signal that you have outgrown it.

Every no-code platform eventually needs an escape hatch, and in Zapier it is called Code by Zapier. It is a built-in action that runs a short snippet of JavaScript or Python as one step in a Zap, receiving values from earlier steps and returning values to later ones.

It is genuinely useful and it is also the single most common source of automations nobody can maintain. Both of those are worth understanding before you reach for it.

How It Works

You add a Code step, choose JavaScript or Python, and map fields from previous steps into named inputs. Inside the snippet those arrive as a dictionary of values - and importantly, they arrive as strings, so a number from a previous step needs parsing.

You return data by assigning to an output object. Return a single object and the following steps see one item; return an array of objects and Zapier treats it as multiple items, running the rest of the Zap once per item.

The environment is sandboxed. There is a short execution timeout, network requests are possible via the standard fetch or HTTP facilities, and you cannot install arbitrary packages. Zapier's own documentation is the authority on current limits and available built-ins - check it rather than trusting any guide, including this one, for exact figures.

The Three Good Uses

1. Reshaping data

The most common and most legitimate case. An API returns a nested structure and the next step needs three flat fields. A date arrives in one format and needs another. A comma-separated string needs to become separate values. Zapier's built-in Formatter handles many of these, but not the awkward ones, and a four-line Code step is clearer than a chain of six Formatter steps.

2. Cleaning and validating input

Trimming whitespace, normalising phone numbers to a consistent format, lowercasing emails, stripping the characters that break a downstream system. This is unglamorous and it prevents a large share of the failures that otherwise appear as mysterious errors three steps later.

3. Fan-out

One trigger produces a list - line items on an order, rows in a payload, recipients in a group - and you need the rest of the Zap to run once per element. Returning an array from a Code step is the clean way to do that, and it is difficult to express any other way.

Where It Goes Wrong

Business logic lives there and nowhere else. The pricing rule, the eligibility check, the routing decision - encoded in a snippet inside a Zap, invisible to anyone who does not open that specific step, with no version history you would recognise as one and no way to test it except by triggering the Zap.

Duplication. The same twenty lines get pasted into four Zaps. Then one of them is fixed and the other three are not, and now the behaviour depends on which path a record took.

Long-running work. A Code step is not the place to loop over a thousand records or wait on a slow API. It will hit the timeout, and the failure mode is a partially completed operation.

Secrets in the snippet. API keys pasted directly into the code, visible to everyone with access to the Zap, and impossible to rotate systematically.

The Signals You Have Outgrown It

Any one of these means it is time to move the logic out:

The snippet is longer than roughly one screen.
You want to write a test for it.
Two or more Zaps need the same logic.
It needs a package that is not available.
It regularly approaches the execution timeout.
Someone other than the author needs to change it.

What to Do Instead

The natural next step is not "rebuild everything as code". It is to move that one piece out and keep the Zap:

Deploy the logic as a small HTTP function - a serverless function or a tiny service, whichever you already have somewhere to run.
Replace the Code step with a Webhooks by Zapier POST to that endpoint.
The Zap keeps its trigger, its filters and its actions. Only the thinking moves.

You immediately get version control, tests, real error handling, proper secret management, and reuse across every Zap that needs it. The Zap stays readable because the complicated part is now behind a named endpoint instead of inside a text box.

The alternative path is moving the whole workflow to a platform where code is a first-class citizen - n8n in particular lets you write function nodes in a workflow you can self-host and version. That is a bigger decision and worth making deliberately rather than by accumulation.

Practical Habits

Comment the intent at the top. Two lines saying what this step is for saves the next person twenty minutes.
Parse inputs explicitly. Everything arrives as a string. Assume nothing.
Fail loudly. Throwing an error is better than returning empty output - a Zap that silently produces nothing is far harder to debug than one that errors.
Never paste a secret. Use Zapier's storage or an authenticated endpoint instead.
Keep a copy outside Zapier. Even a file in a repository is better than one copy inside a step nobody backs up.

Used for what it is - a transformation step between two other steps - Code by Zapier is excellent. Used as the place your business rules live, it becomes the most fragile part of your operations.

If you have Code steps that have grown into something nobody wants to touch, book a free call. Related: Zapier versus custom code, n8n versus Make versus Zapier, and Zapier alternatives for small business.