Skip to main content
The Zapier SDK CLI lets you explore and run actions across apps directly from your terminal, authenticated, with no OAuth setup required. It’s the fastest way to understand what an app can do and what inputs an action needs before writing any code.

Set up with your AI

Your agent runs the commands for you

Open in Codex

Open in Claude Code

Open in Cursor

Open in VS Code Copilot

Your agent walks you through the process

Open in ChatGPT

Open in Claude

Open in Perplexity

Using another IDE agent (Cline, Windsurf, etc.)? Copy this prompt.
CLI and SDK, complementary by design

The CLI is built on the SDK and is the fastest way to explore — discover what an app can do, inspect input fields, and run actions interactively. You or an agent can go back and forth with it freely: try an action, check what fields it needs, adjust inputs, repeat. For some agent use cases, the CLI alone may be enough.

When you need something repeatable, embedded, or production-grade — a scheduled workflow, a backend integration, a tool in an AI agent — reach for the TypeScript SDK. Everything you learned with the CLI transfers directly: same app keys, same action keys, same input shapes.


Before You Start

Install the CLI and authenticate:
Use signup when you’re new to Zapier. Use login when you already have an account. Both commands finish in the same place: the CLI creates a local SDK credential, marks it as the default, and createZapierSdk() can authenticate without code changes.
signup opens Zapier’s account creation flow first. login starts from an existing Zapier account. Both commands support the same authentication flags:
For CI pipelines and server deployments, you can also create long-lived client credentials. Learn how to set them up.
Response
Save the client_secret; it’s only shown once. Use the returned client_id and client_secret wherever the CLI needs authentication instead of the locally stored credential.To remove a credential pair when you no longer need it, use the delete-client-credentials command and pass the client_id:

Key Concepts

CLI commands work with three concepts: apps, connections, and actions. An app is an integration — Google Sheets, Slack, GitHub. Each app has an app key, a short identifier you use in every command (google-sheets, slack, github). A connection is an authenticated account for an app — your personal Google account, a Slack bot account, a CI GitHub account. Each connection has a connection ID that you pass with every action call to tell the CLI which account to use. An action is something the app can do — create a spreadsheet, add a row, send a message. Each action has input fields: the specific values it needs to run. Some input fields are static; others are dynamic and only appear once you provide context (like which spreadsheet you’re targeting as each may have different columns).

Apps and Connections

App keys come in two forms. Commands take an app as a positional argument, which can be a short slug like google-sheets or a longer key like GoogleSheetsV2CLIAPI. Slugs are easier to type and remember, so use those when you can. When in doubt, search:
Response
Use the slug as the app in all subsequent action commands for that specific app. Every action needs a connection ID. A connection ID ties a command to a specific authenticated account, like your Google Sheets connection, Slack account, or GitHub org. List all connections you already have for an app:
Response
Find the first matching connection for your account:
Response
Hold onto that id. You’ll use it in every action call.
find-unique-connection has the same syntax as find-first-connection, but throws an error if more than one connection matches. Use this when you need to be certain you got the right account, not just the first one.
Response
list-connections returns all matching connections as a paginated list. Useful when you have multiple Google accounts connected and need to pick the right one.
find-first-connection with --owner me filters to only connections you own, useful in shared Zapier accounts:
Filter to expired connections to audit which connections need to be re-authenticated:

Walkthrough: Create a Spreadsheet, Then Add Rows

This walkthrough shows the full pattern: connect to an app, discover what it can do, figure out what inputs an action needs, and run it. We’ll create a new Google Sheet with a header row and then add rows to it.

Explore available actions

Response
Filter by action type to narrow things down:
Response
get-action is for when you already know the action key and want its full detail instead of scanning a list:
Response
--page-size is useful when apps like Salesforce or HubSpot have many actions and you want to page through the results

Inspect spreadsheet creation inputs

Before running an action, use list-action-input-fields to see exactly what it expects:
Response
get-action-input-fields-schema returns the same information as a JSON Schema object instead of a list. Useful when you’re building an agent tool definition or need machine-readable validation rules:
Response

Create a spreadsheet

Response
The headers field populates the first row of the default sheet (Sheet1) in one step — no separate worksheet creation needed. Note the spreadsheet id — that’s your spreadsheetId. The response also includes a worksheetId field (the numeric sheet ID, 0 for the default sheet); you’ll pass both to add_row.

Inspect row creation inputs

Without context, list-action-input-fields returns only the structural fields — spreadsheet and worksheet selectors, but no column fields:
Response
The column fields are dynamic — they don’t exist until the action knows which spreadsheet and worksheet you’re targeting. Pass those IDs to get the full field list, including the per-column keys:
Response
COL$A maps to “Name”, COL$B to “Email”, and COL$C to “Role” — the headers you defined when creating the spreadsheet. These are the keys you’ll use in --inputs below.

Add rows

Response
Response
Response
Check your spreadsheet; all three rows should be there.

Zero Auth Setup

Here’s what you just did without writing a single line of auth code:
If a user has a Google account connected to Zapier, find-first-connection gives you authenticated access immediately. This is true for all apps on Zapier.

Beyond built-in actions

Zapier’s apps cover the most common operations, but every API has endpoints that go beyond what’s been modeled as actions. For those cases, use curl — it makes authenticated requests to any endpoint directly, with credentials injected automatically from the same connection you’ve been using.

GET: Read row data

The Google Sheets API’s values endpoint returns the raw cell data for a named range, useful as a ground-truth read outside of the SDK action layer:
Response

GET: Spreadsheet metadata

The spreadsheets.get endpoint returns full spreadsheet metadata (sheet names, tab structure, locale, timezone) that isn’t exposed as a built-in Zapier action:
Response
No token. No Authorization header. No OAuth setup. Zapier injects the user’s stored credentials automatically.

POST: Add a row directly via the API

Response

Scripting and chaining commands

Every command supports --json for raw output, making it easy to pipe into jq or chain into shell scripts. A common pattern: grab a connection ID and use it immediately:
Extract just the action keys for an app:

Next Steps