Code steps can be used as both triggers and actions.
Dates and times in Code actions use the UTC timezone, even if a different one is set for the account or the Zap.
In your code step, you have access to the
inputData dictionary variable where all values will be strings. Since the amount of data that might feed into your script might be large or highly dynamic, you'll need to define an
inputData mapping via Zapier’s GUI by providing a key and value.
It's not possible to map
inputData in Code by Zapier triggers.
Code steps return a single
output variable, which is an object or array of objects that will be the result of this step. You can explicitly return early.
If the output is an array of objects, subsequent steps will run multiple times, once for each object in the array.
In this example, each object in the array is returned separately. Subsequent actions will run once for each object.
To return the whole array as line items instead, you can add
line_items as the parent key for the output.
"line_items" : [
In this example, the array is returned as a set of line items. Any subsequent actions will only run once.
If you use Code by Zapier as the Zap's trigger and an empty array is returned, nothing will happen. The behavior will be similar to a polling trigger that did not get any results in the HTTP response. This functionality is exclusive to triggers.
There are a few utilities you have access to in Code steps:
callback(err, output): a callback if you need to do asynchronous work—whatever you set to the output data variable is ignored since it's provided directly here. The Zap will inspect the code and make a best guess as to whether it's using a callback or not.
callback(err, output) tells Zapier that your task is done executing. If you have multiple asynchronous calls, each invoking
callback(err, output) with their desired responses, only the first one to execute will count. Subsequent invocations to
callback(err, output) will be picked up by the next execution of your Zap, but will not affect that task's execution, other than side effects like
fetch: an easy to use HTTP client.
console.log: this utility allows you to debug your function. You'll need to test your Zap to see the values. The logs are returned in a
runtime_meta added automatically to the
StoreClient : a built-in utility for storing and retrieving data between Zap runs.
Running your Zap via the dashboard is the canonical way to confirm the behavior you expect. Your Zap History will have all relevant details around the Code step's
output and logs. The test step in the editor can be used for a tighter feedback loop.
- The environment in which your Code steps run (AWS Lambda) has an I/O limit of 6 MB. The total size of the code and the data processed by the Code step cannot exceed that. If you're hitting this error, try to limit the amount of data returned from your function. For instance, don't return an entire JSON structure, just the keys you need.
- Free users can run scripts of up to 1 second and 128 MB of RAM. Paid users can run scripts of up to 10 seconds and 256 MB of RAM. Your Zap will hit an error if it exceeds these limits.
- You cannot require external libraries, or install or import libraries commonly referred to as "npm modules". Only the standard node.js library and the
fetch package are available in the Code by Zapier app.
fetch is already included in the namespace.
Some common error messages you might encounter include:
- Scripting payload too large: this means the total amount of data returned from your function is too large. See Limitations with code steps.
- NoneType object does not support item assignment: this error can happen when you redefine some of the important variables in the function, such as
callback. Lambda expects
callback to be there to complete an async function, so it'll produce errors if it's redefined.
- Process exited before completing request: this typically happens if your script completes without calling
callback. The most common case is if your
fetch().then() doesn't have a
.catch() for errors. Adding a
.catch(callback) will solve this, as the error will be passed as the first argument.
If you're using a linter, you can safely ignore warnings about unused variables for
callback. Those are provided for your convenience, but you don't need to use them. If you see something else listed, you may need to debug your code.