Zapier

Studio's Zapier action runs one action on your Zapier MCP server. One credential reaches every app you enable on that server, so a workflow can send an email, post to a channel or update a record after a transfer finishes, without a connector for each app. Studio calls Zapier; your files never pass through Zapier.

This page describes Studio 1.0.27 and later. If you are updating from an earlier Studio, read Upgrading from an earlier Studio first.

Connect Zapier

1. On mcp.zapier.com, create an MCP server, enable the apps you want Studio to reach, and connect an account for any app that needs one. A server with no apps enabled connects fine and can do nothing.
2. In Studio, open Credentials → New credential → Native providers → Zapier and paste the server's URL into MCP server URL. API key is optional: fill it in only if your server also requires a bearer token.
3. Run the connection test. It lists the apps enabled on the server, and warns when there are none.

The server URL contains a secret: anyone who has it can run the server's actions. Studio stores it encrypted and never sends it back to the browser. Regenerating the URL on mcp.zapier.com stops the old one working; paste the new URL into the credential.

Find an action

A Zapier MCP server offers the same tools whatever it has enabled. An app's action runs through one of two of them, execute_zapier_write_action to send, create or update something, or execute_zapier_read_action to search or read, and the tool's arguments name the app and the action. Those names are identifiers only your server knows, so let Studio look them up:

• Add a Zapier actions step, pick the credential and run the workflow. The step's actions output lists every enabled action with its app, its name, the tool that runs it and its arguments, ready to paste into a Zapier action step.
• In a Zapier action step, the Zapier tool field lists the actions enabled on the credential's server as you edit.

Run an action

Add a Zapier action step and set:

• Zapier credential: the credential from Connect Zapier.
• Zapier tool: execute_zapier_write_action or execute_zapier_read_action, as listed for the action.
• Arguments: the action's arguments, with its own fields under params:

{
  "selected_api": "ZapierMailCLIAPI",
  "action": "outbound",
  "tool_name": "email_by_zapier_send_outbound_email",
  "params": {
    "to": "ops@example.com",
    "subject": "Nightly transfer finished",
    "body": "Transfer ${steps.<transfer>.name} finished with status ${steps.<transfer>.status}"
  }
}

${…} expressions resolve anywhere inside the arguments, so a field can carry a run's details. A step's status and error resolve even when that step failed, so the same action can report a failure from the false branch of a Decision node. To see an action's fields, open it on mcp.zapier.com.

The step's outputs are ok, toolName, content (what Zapier reported, as text) and result (Zapier's structured result, when it returns one).

Failures and retries

• Refusals fail the step. When Zapier reports that the action failed, the step fails instead of returning ok: false, and it is not retried: the same arguments would be refused again.
• Connection problems are retried. Network failures and Zapier 5xx responses are retried with backoff. A rejected credential is not retried.
• A success is not repeated. Once an action succeeds, a retry of the step returns the recorded result instead of running the action again. Zapier offers no other protection against running an action twice.

Start a Zap from a workflow

A Zapier MCP server runs actions; it cannot start a Zap. A Zap starts when its own trigger fires, so a workflow starts one by producing the event the Zap's trigger waits for:

• On any Zapier plan: give the Zap the trigger Email by Zapier → New Inbound Email, and add a Zapier action step that sends Email by Zapier's Send Outbound Email to the Zap's @zapiermail.com address, as in the example above. The email's subject and body arrive as the Zap's trigger fields.
• On paid Zapier plans: give the Zap the trigger Webhooks by Zapier → Catch Hook, and add a Webhook step pointed at the hook's URL. Each callback arrives as one trigger event, carrying the run's identity (workflowRunId, stepRunId) and the payload you bind. Webhooks by Zapier is a Premium app: on a Free plan, Zapier accepts the request but the Zap cannot be turned on.

Zapier documents no de-duplication on the Idempotency-Key header the Webhook step sends. If running a Zap twice for one event would matter, have the Zap skip a stepRunId it has already processed.

Upgrading from an earlier Studio

Studio 1.0.27 changed the Zapier action to fit Zapier's current MCP servers:

• Save each workflow that has a Zapier step once after updating. The action's code changed, so Studio will not run those workflows until they are saved again, which approves the new version.
• The Instructions input is gone. No current Zapier tool accepts one. Move what a step said in Instructions into its Arguments, using a Zapier actions step to get the app and action.

Limits

• Zapier's plan limits apply. Email by Zapier sends up to 5 emails a day on Free and Trial plans, and up to 10 an hour on paid plans.
• An action, not a Zap. The Zapier action runs one action per step. To run a Zap's multi-step logic, start the Zap as described above.
• Reachability. Studio calls mcp.zapier.com from the machine it runs on, so that machine needs outbound internet access.

Costs

A Zapier step costs no Beam credits: a Studio workflow run is free, its steps included. Only the transfers a run starts are charged. What Zapier charges for the actions it runs is set by your Zapier plan.