zapier-platform

Zapier CLI Reference

These are the generated docs for all Zapier platform CLI commands.

You can install the CLI with npm install -g zapier-platform-cli.

$ npm install -g zapier-platform-cli

Commands

analytics

Show the status of the analytics that are collected. Also used to change what is collected.

Usage: zapier analytics

Flags

Examples

build

Build a pushable zip from the current directory.

Usage: zapier build

This command does the following:

This command is typically followed by zapier upload.

Flags

canary:create

Create a new canary deployment, diverting a specified percentage of traffic from one version to another for a specified duration.

Usage: zapier canary:create VERSIONFROM VERSIONTO

Only one canary can be active at the same time. You can run zapier canary:list to check. If you would like to create a new canary with different parameters, you can wait for the canary to finish, or delete it using zapier canary:delete a.b.c x.y.z.

Note: this is similar to zapier migrate but different in that this is temporary and will “revert” the changes once the specified duration is expired.

Only use this command to canary traffic between non-breaking versions!

Arguments

Flags

Examples

canary:delete

Delete an active canary deployment

Usage: zapier canary:delete VERSIONFROM VERSIONTO

Arguments

Examples

canary:list

List all active canary deployments

Usage: zapier canary:list

Flags

Examples

convert

Convert a Visual Builder integration to a CLI integration.

Usage: zapier convert INTEGRATIONID PATH

The resulting CLI integration will be identical to its Visual Builder version and ready to push and use immediately!

If you re-run this command on an existing directory it will leave existing files alone and not clobber them.

You’ll need to do a zapier push before the new version is visible in the editor, but otherwise you’re good to go.

Arguments

Flags

delete:integration

Delete your integration (including all versions).

Usage: zapier delete:integration

This only works if there are no active users or Zaps on any version. If you only want to delete certain versions, use the zapier delete:version command instead. It’s unlikely that you’ll be able to run this on an app that you’ve pushed publicly, since there are usually still users.

Flags

Aliases

delete:version

Delete a specific version of your integration.

Usage: zapier delete:version VERSION

This only works if there are no users or Zaps on that version. You will probably need to have run zapier migrate and zapier deprecate before this command will work.

Arguments

Flags

deprecate

Mark a non-production version of your integration as deprecated, with removal by a certain date.

Usage: zapier deprecate VERSION DATE

Use this when an integration version will not be supported or start breaking at a known date.

Zapier will send an email warning users of the deprecation once a date is set, they’ll start seeing it as “Deprecated” in the UI, and once the deprecation date arrives, if the Zaps weren’t updated, they’ll be paused and the users will be emailed again explaining what happened.

After the deprecation date has passed it will be safe to delete that integration version.

Do not use this if you have non-breaking changes, such as fixing help text.

Arguments

Flags

Examples

describe

Describe the current integration.

Usage: zapier describe

This command prints a human readable enumeration of your integrations’s triggers, searches, and creates as seen by Zapier. Useful to understand how your resources convert and relate to different actions.

Flags

env:get

Get environment variables for a version.

Usage: zapier env:get VERSION

Arguments

Flags

Examples

env:set

Set environment variables for a version.

Usage: zapier env:set VERSION [KEY-VALUE PAIRS...]

Arguments

Flags

Examples

env:unset

Unset environment variables for a version.

Usage: zapier env:unset VERSION [KEYS...]

Arguments

Flags

Examples

history

Get the history of your integration.

Usage: zapier history

History includes all the changes made over the lifetime of your integration. This includes everything from creation, updates, migrations, admins, and invitee changes, as well as who made the change and when.

Flags

init

Initialize a new Zapier integration with a project template.

Usage: zapier init PATH

After running this, you’ll have a new integration in the specified directory. If you re-run this command on an existing directory, it will prompt before overwriting any existing files.

This doesn’t register or deploy the integration with Zapier - try the zapier register and zapier push commands for that!

Arguments

Flags

Examples

integrations

List integrations you have admin access to.

Usage: zapier integrations

This command also checks the current directory for a linked integration.

Flags

Aliases

invoke

Invoke an auth operation, a trigger, or a create/search action locally.

Usage: zapier invoke [ACTIONTYPE] [ACTIONKEY]

This command emulates how Zapier production environment would invoke your integration. It runs code locally, so you can use this command to quickly test your integration without deploying it to Zapier. This is especially useful for debugging and development.

This command loads environment variables and authData from the .env file in the current directory. If you don’t have a .env file yet, you can use the zapier invoke auth start command to help you initialize it, or you can manually create it.

The zapier invoke auth start subcommand will prompt you for the necessary auth fields and save them to the .env file. For OAuth2, it will start a local HTTP server, open the authorization URL in the browser, wait for the OAuth2 redirect, and get the access token.

Each line in the .env file should follow one of these formats:

For example, a .env file for an OAuth2 integration might look like this:

CLIENT_ID='your_client_id'
CLIENT_SECRET='your_client_secret'
authData_access_token='1234567890'
authData_refresh_token='abcdefg'
authData_account_name='zapier'

To test if the auth data is correct, run either one of these:

zapier invoke auth test   # invokes authentication.test method
zapier invoke auth label  # invokes authentication.test and renders connection label

To refresh stale auth data for OAuth2 or session auth, run zapier invoke auth refresh.

Once you have the correct auth data, you can test an trigger, a search, or a create action. For example, here’s how you invoke a trigger with the key new_recipe:

zapier invoke trigger new_recipe

To add input data, use the --inputData flag. The input data can come from the command directly, a file, or stdin. See EXAMPLES below.

When you miss any command arguments, such as ACTIONTYPE or ACTIONKEY, the command will prompt you interactively. If you don’t want to get interactive prompts, use the --non-interactive flag.

The --debug flag will show you the HTTP request logs and any console logs you have in your code.

The following is a non-exhaustive list of current limitations and may be supported in the future:

Arguments

Flags

Examples

jobs

Lists ongoing migration or promotion jobs for the current integration.

Usage: zapier jobs

A job represents a background process that will be queued up when users execute a “migrate” or “promote” command for the current integration.

Each job will be added to the end of a queue of “promote” and “migration” jobs where the “Job Stage” will then be initialized with “requested”.

Job stages will then move to “estimating”, “in_progress” and finally one of four “end” stages: “complete”, “aborted”, “errored” or “paused”.

Job times will vary as it depends on the size of the queue and how many users your integration has.

Jobs are returned from oldest to newest.

Flags

Examples

Link the current directory with an existing integration.

Usage: zapier link

This command generates a .zapierapprc file in the directory in which it’s ran. This file ties this code to an integration and is referenced frequently during push and validate operations. This file should be checked into source control.

If you’re starting an integration from scratch, use zapier init instead.

Flags

login

Configure your ~/.zapierrc with a deploy key.

Usage: zapier login

Flags

logout

Deactivate your active deploy key and reset ~/.zapierrc.

Usage: zapier logout

Flags

logs

Print recent logs.

Usage: zapier logs

Logs are created when your integration is run as part of a Zap. They come from explicit calls to z.console.log(), usage of z.request(), and any runtime errors.

This won’t show logs from running locally with zapier test, since those never hit our server.

Flags

migrate

Migrate a percentage of users or a single user from one version of your integration to another.

Usage: zapier migrate FROMVERSION TOVERSION [PERCENT]

Start a migration to move users between different versions of your integration. You may also “revert” by simply swapping the from/to verion strings in the command line arguments (i.e. zapier migrate 1.0.1 1.0.0).

Only use this command to migrate users between non-breaking versions, use zapier deprecate if you have breaking changes!

Migration time varies based on the number of affected Zaps. Be patient and check zapier jobs to track the status. Or use zapier history if you want to see older jobs.

Since a migration is only for non-breaking changes, users are not emailed about the update/migration. It will be a transparent process for them.

We recommend migrating a small subset of users first, via the percent argument, then watching error logs of the new version for any sort of odd behavior. When you feel confident there are no bugs, go ahead and migrate everyone. If you see unexpected errors, you can revert.

You can migrate a specific user’s Zaps by using --user (i.e. zapier migrate 1.0.0 1.0.1 --user=user@example.com). This will migrate Zaps that are private for that user. Zaps that are

will not be migrated.

Alternatively, you can pass the --account flag, (i.e. zapier migrate 1.0.0 1.0.1 --account=account@example.com). This will migrate all Zaps owned by the user, Private & Shared, within all accounts for which the specified user is a member.

The --account flag should be used cautiously as it can break shared Zaps for other users in Team or Enterprise accounts.

You cannot pass both PERCENT and --user or --account.

You cannot pass both --user and --account.

Arguments

Flags

Examples

promote

Promote a specific version to public access.

Usage: zapier promote VERSION

Promote an integration version into production (non-private) rotation, which means new users can use this integration version.

Promotes are an inherently safe operation for all existing users of your integration.

After a promotion, go to your developer platform to close issues that were resolved in the updated version.

If your integration is private and passes our integration checks, this will give you a URL to a form where you can fill in additional information for your integration to go public. After reviewing, the Zapier team will approve to make it public if there are no issues or decline with feedback.

Check zapier jobs to track the status of the promotion. Or use zapier history if you want to see older jobs.

Arguments

Flags

Examples

pull

Retrieve and update your local integration files with the latest version.

Usage: zapier pull

This command updates your local integration files with the latest version. You will be prompted with a confirmation dialog before continuing if there any destructive file changes.

Zapier may release new versions of your integration with bug fixes or new features. In the event this occurs, you will be unable to do the following until your local files are updated by running zapier pull:

Flags

push

Build and upload the current integration.

Usage: zapier push

This command is the same as running zapier build and zapier upload in sequence. See those for more info.

Flags

register

Register a new integration in your account, or update the existing one if a .zapierapprc file is found.

Usage: zapier register [TITLE]

This command creates a new integration and links it in the ./.zapierapprc file. If .zapierapprc already exists, it will ask you if you want to update the currently-linked integration, as opposed to creating a new one.

After registering a new integration, you can run zapier push to build and upload your integration for use in the Zapier editor. This will change .zapierapprc, which identifies this directory as holding code for a specific integration.

Arguments

Flags

Examples

scaffold

Add a starting trigger, create, search, or resource to your integration.

Usage: zapier scaffold ACTIONTYPE NOUN

The first argument should be one of trigger|search|create|resource followed by the noun that this will act on (something like “contact” or “deal”).

The scaffold command does two general things:

You can mix and match several options to customize the created scaffold for your project.

Arguments

Flags

Examples

team:add

Add a team member to your integration.

Usage: zapier team:add EMAIL ROLE [MESSAGE]

These users come in three levels:

Team members can be freely added and removed.

Arguments

Flags

Examples

Aliases

team:get

Get team members involved with your integration.

Usage: zapier team:get

These users come in three levels:

Use the zapier team:add and zapier team:remove commands to modify your team.

Flags

Aliases

team:remove

Remove a team member from all versions of your integration.

Usage: zapier team:remove

Admins will immediately lose write access to the integration. Collaborators will immediately lose read access to the integration. Subscribers won’t receive future email updates.

Flags

Aliases

test

Test your integration via the “test” script in your “package.json”.

Usage: zapier test

This command is a wrapper around npm test that also validates the structure of your integration and sets up extra environment variables.

You can pass any args/flags after a --; they will get forwarded onto your test script.

Flags

Examples

upload

Upload the latest build of your integration to Zapier.

Usage: zapier upload

This command sends both build/build.zip and build/source.zip to Zapier for use.

Typically we recommend using zapier push, which does a build and upload, rather than upload by itself.

Flags

users:add

Add a user to some or all versions of your integration.

Usage: zapier users:add EMAIL [VERSION]

When this command is run, we’ll send an email to the user inviting them to try your integration. You can track the status of that invite using the zapier users:get command.

Invited users will be able to see your integration’s name, logo, and description. They’ll also be able to create Zaps using any available triggers and actions.

Arguments

Flags

Examples

Aliases

users:get

Get a list of users who have been invited to your integration.

Usage: zapier users:get

Note that this list of users is NOT a comprehensive list of everyone who is using your integration. It only includes users who were invited directly by email (using the zapier users:add command or the web UI). Users who joined by clicking links generated using the zapier user:links command won’t show up here.

Flags

Aliases

Get a list of links that are used to invite users to your integration.

Usage: zapier users:links

Flags

users:remove

Remove a user from all versions of your integration.

Usage: zapier users:remove EMAIL

When this command is run, their Zaps will immediately turn off. They won’t be able to use your app again until they’re re-invited or it has gone public. In practice, this command isn’t run often as it’s very disruptive to users.

Arguments

Flags

Aliases

validate

Validate your integration.

Usage: zapier validate

Run the standard validation routine powered by json-schema that checks your integration for any structural errors. This is the same routine that runs during zapier build, zapier upload, zapier push or even as a test in zapier test.

Flags

Examples

versions

List the versions of your integration available for use in the Zapier editor.

Usage: zapier versions

Flags