z.legacyScripting.run()
. To make integrations written in the old environment run without modification, in the new environment Zapier ‘wraps’ your custom code and API configuration, and created a runtime library that emulates the behavior of the old platform. So each time you see this, you can recognize it as an artifact of this emulation - we’re calling into the emulator to perform the operation we need using your original code and configuration.
Where you added custom scripting code, the z.legacyScripting
will call these functions to drive your triggers, actions, and authentication transactions.
Note: Zapier recommends to understand versioning model of the Platform UI before making any code changes.→ Find detailed documentation on how to edit your integration’s code in Legacy Scripting.
Note: If you’re making changes to the code in the Legacy Web Builder tab, the following statements do not apply. That code is run in an “emulated” context and works just like the old environment.
Tip: A handy way to understand this is to have a look at the schema of the integration definition you’re building. Here you’ll see the structure of the definition of a polling trigger. Notice that the perform
field takes a request configuration object, or it simply takes a Javascript function. The Platform UI reflects this. When you configure an API interaction, you use the Form Mode to configure a request, or you use Code Mode to write a function to be called instead.
perform
function that takes a bundle as input and is expected to return data when the request handling is completed.
z.request
library works very similarly to the promise-based Fetch API, so most articles and tutorials about that apply to working with custom code in Zapier’s environment.
z.require
.
If you need, or prefer to use, a 3rd party Javascript library you’ll want to switch to the Platform CLI where you can install modules from npm and reference them throughout your code.