Your agent needs to act across the apps your customers already use. Zapier ships two ways to get there: a hosted MCP server at mcp.zapier.com and a set of public APIs at api.zapier.com plus a TypeScript SDK. Unlike most tools in this series, the capability gap here is not the interesting part; Zapier MCP is headless-capable and covers most of what an agent needs to run actions. The interesting part is identity. Everything Zapier exposes is scoped to a Zapier user account, and that single fact reshapes how a multi-tenant B2B agent has to be built.
These are two different shapes of the same underlying integration layer. One presents it as a self-navigating tool surface; the other presents it as endpoints you call explicitly.
Zapier MCP is a hosted Streamable HTTP server that fronts Zapier's integration catalog. Zapier's MCP quickstart puts that catalog at 9,000+ apps and 40,000+ actions. It shipped in 2025 and is now generally available on all Zapier plans, enabled by default at the account level, and covered by Zapier's SOC 2 Type II certification.
Three authentication methods are documented: a client-specific server URL backed by OAuth, a connection token for unlisted clients, and an API key for SDK integrations. Tokens and keys are passed as Authorization: Bearer <token> against https://mcp.zapier.com/api/v1/connect.
Official docs: Zapier MCP documentation and the Zapier MCP product page.
Most MCP servers expose one tool per capability. Zapier does not, because a per-action surface across 40,000 actions is unusable. Instead the server exposes 15 static meta-tools across action management, execution, configuration, Skills, and feedback.
In the default dynamic discovery mode, auto_provision_mcp runs on OAuth connect and provisions tools from the apps the user already connected in Zapier. The agent then expands its own reach at runtime. A manual configuration mode exists for teams that need a fixed, pre-declared toolset instead.
There is no single "Zapier API." There are four surfaces an agent builder needs to distinguish, and picking the wrong one is the most common architectural mistake on this path.
The Actions API at https://api.zapier.com/actions/v1/ creates and runs stored actions against a connection_id. The Trigger Inbox API delivers app events through an SQS-style pull queue. The Workflow API creates and manages Zaps programmatically for embedded experiences. The Zapier SDK, a TypeScript package, wraps action execution with runAction, connection lookup, and a fetch escape hatch for arbitrary authenticated calls.
Auth across the public APIs is OAuth 2.0 with both authorizationCode and clientCredentials flows, scope external, token endpoint https://zapier.com/oauth/token.
Official docs: Zapier API reference and the Zapier SDK.
Four dimensions decide this: what the agent can do, what credential model each path forces, what breaks in production, and which workloads each one actually fits.
The MCP server owns the interactive execution loop. The APIs own everything asynchronous, event-driven, and programmatically governed.
The gap is not breadth of apps; both paths reach the same catalog. The gap is execution semantics.
The Actions API runs asynchronously: you POST to /stored-actions/{id}/run, get a 202 with a run ID, and poll /runs/{run_id} or receive a callback_url POST. It accepts an idempotency_id that deduplicates identical requests within 72 hours, and results are retained for seven days. None of that exists on the MCP surface. For a nightly pipeline that must not double-post to Slack after a retry, the idempotency key alone decides the path.
The second gap is events. The Trigger Inbox API is the only way to consume app events, and it is architecturally a queue, not a tool call.
Zapier MCP is the rare hosted MCP server that does not force interactive OAuth. Static credentials work, which means a background agent can authenticate without a browser. That removes the blocker that defines the Notion and Salesforce comparisons in this series.
What it does not remove is the identity ceiling. A connection token authorizes a server that belongs to one Zapier user. The Zapier SDK's client credentials, per Zapier's deployment guide, "act on behalf of the Zapier user who created them." Both paths converge on the same thing: the credential your agent holds is a Zapier user identity, not a tenant identity.
Zapier's security and governance documentation is explicit about the boundaries. Auto-provisioning covers the authorizing user's own connections only; apps shared by another Zapier user are excluded. App connections cannot be shared at all. Server access sharing lets a colleague view or manage tools, but it does not let them connect a client or run tools on another user's behalf.
For a B2B agent serving 40 users across 8 customer orgs, that means 40 separate Zapier accounts, 40 server configurations, and 40 credentials. Zapier's MCP Embed narrows this by issuing a per-user server URL, but authentication still runs on a single shared embed secret. Isolation becomes a property of a URL you stored correctly, not of a credential.
There is a second credential layer most teams miss until an audit. Your agent holds a Zapier credential. Zapier separately holds the OAuth grant to Slack, HubSpot, or Gmail.
Revoking the Zapier token does not revoke the downstream Slack grant. Revoking the Slack grant inside Slack does not invalidate the Zapier token; the next tool call simply fails at the far end. When a customer offboards an employee, you need both layers torn down, and no single Zapier surface does both for you. This is a core challenge in credential ownership across agent tool-calling patterns.
Zapier manages the server, the tool schemas, and every downstream app credential. That is a genuine operational win: you are not writing an OAuth client per app, and Zapier absorbs upstream API changes.
What you still own is more than it looks. Every successful MCP tool call consumes two Zapier tasks from the account's shared allowance. Failed calls are free. Batches multiply: Zapier's own example puts "search and update 10 records" at 11 tool calls and 22 tasks. When the allowance is exhausted, MCP tool calls stop working account-wide until reset or upgrade.
That shared allowance is a cross-tenant coupling most teams do not model. One agent looping on a retry burns tasks that every other agent on the same Zapier account depends on. The failure is not isolated to the caller; it is account-wide, and it presents as tool calls that suddenly stop.
Governance has a similar shape. App and action restrictions cannot be scoped to MCP alone; any restriction you set applies across all Zapier features for the whole account. And the SDK's fetch method makes authenticated calls that Zapier documents as not currently subject to those org restriction policies.
Dynamic discovery is a feature for assistants and a liability for pipelines. An agent that can call enable_zapier_action mid-run can change its own tool surface between executions, which means the same prompt can produce different capabilities on Tuesday than it did on Monday. Manual configuration mode is the fix, and it should be the default for anything scheduled.
Observability is the other split. MCP tool calls are logged in Zapier's History tab and the account audit log, attributed to the Zapier user. If your agent runs on one service account, every action in that log resolves to the same identity, and correlating a Zapier action back to the customer who triggered it becomes an exercise in timestamp matching. For production systems, agent tool observability requires far more than timestamp correlation.
Two constraints matter for regulated buyers. Zapier MCP runs on multi-tenant cloud infrastructure with customer data stored in AWS US-East-1; region-specific residency is not available unless separately agreed, and dedicated VPC or on-premises deployment is not offered. Security is achieved through logical segregation.
Incident response is manual: Zapier can enable or disable MCP access for an account on request through your account manager. There is no programmatic kill switch you control.
Both lists below assume a production agent, not a prototype. The split is about execution guarantees and who the agent is acting as.
Use Zapier MCP when:
Use the Zapier APIs and SDK when:
Scalekit ships a Zapier MCP connector under the connection name zapiermcp. It exposes 14 of Zapier's 15 meta-tools as execute_tool targets, prefixed with zapiermcp_. The custom code action tool is not in the catalog, which is the right default for production pipelines.
For most tools in this series Scalekit publishes separate API and MCP connectors. Zapier is currently MCP-only in the connector catalog. If your agent needs the Actions API or Trigger Inbox API, register those endpoints through bring your own connector and they inherit the same vault, scoping, and audit chain as the prebuilt connector.
Scalekit resolves the per-user Zapier credential at request time. The identifier you pass is your own user ID, and it is the join key between your tenant model and the Zapier account behind the connected account.
The connection_name string must match the connection name configured in your Scalekit dashboard exactly. This is the single most common integration error.
The Node SDK mirrors the Python surface with camelCase method names.
Before the agent loop runs, retrieve the tools this user's connected account is authorized to call. This is not tool discovery against an unknown catalog; it is a scoped, deterministic surface derived from what the user actually authorized.
Scalekit returns native LangChain StructuredTool objects, so no schema reshaping is needed. This integrates cleanly with LangChain tool calling patterns.
Full working examples for other stacks are in the Scalekit LangChain guide and the adjacent Anthropic, OpenAI, Google ADK, and Mastra samples.
The 14 meta-tools include four that let an agent rewrite its own capabilities: enable, disable, create Skill, delete Skill. For a scheduled agent, that is more authority than the job requires.
Virtual MCP Servers let you declare exactly which tools an agent role can see. One server definition serves every user; a short-lived session token bound to a specific user is minted before each run. The endpoint is static; the identity is not.
Three tools instead of fourteen removes the agent's ability to expand its own reach mid-run, and it cuts the tokens spent on tool definitions before the agent does any work. Setup details are in the Virtual MCP setup guide.
Zapier is the connector where a shared credential is most tempting, because one Zapier account technically reaches every app your customers use. It is also the connector where a shared credential does the most damage, because a single token spans thousands of downstream systems.
Scalekit inverts that. Each user authorizes once, their credential lives in an encrypted vault namespaced per tenant, and it is resolved server-side at call time so it never enters the agent runtime or the model context.
Every tool call is logged with full attribution: who authorized it, which agent ran it, which tool executed, and what came back. Those logs export to Datadog, Splunk, or any SIEM. When a Zapier action surfaces in an audit, it resolves to a person, not a service account. This is exactly the kind of audit trail for agent auth that enterprise buyers require.
Both paths hand you a credential per user and stop there. The MCP path gives you an OAuth session or a connection token. The API path gives you an OAuth token or a client credentials pair. Neither gives you a vault, rotation logic, or a revocation flow.
In a multi-tenant Zapier agent, every user has their own Zapier credential, and each one needs to be encrypted at rest, isolated per tenant, refreshed before expiry, and invalidated on disconnect. Fifty customers is fifty credential lifecycles.
Zapier's identity model makes this sharper than most. Because credentials are user-scoped by construction and connections cannot be shared, there is no supported shortcut to a single org-wide credential. The per-user model is not optional; it is the only correct model, and it is entirely yours to operate. Understanding how to handle token refresh for AI agents at this scale is non-trivial.
The Scalekit Zapier MCP connector handles the OAuth flow, per-user token storage, and automatic refresh for both paths. The MCP versus API decision does not change your auth infrastructure.
If your agent is interactive and the user is present, build on Zapier MCP. The constant-size meta-tool surface is the right answer to a 40,000-action catalog, and dynamic discovery lets the agent reach apps you never anticipated.
If your agent runs on a schedule, reacts to events, or cannot tolerate a duplicate write, build on the Actions API and the Trigger Inbox API. Idempotency keys, async callbacks, and pinned schemas are what unattended execution requires, and none of them exist on the MCP surface.
Most production Zapier agents will run both. What does not change between them is that every user brings their own Zapier credential, and that credential is the part that needs production-grade infrastructure. The patterns described here mirror the broader challenge of moving tool-calling auth from single-tenant to multi-tenant architectures.
Building on Zapier MCP and hitting the identity ceiling, the task accounting, or the two-layer revocation problem? Come compare notes: join the Scalekit Slack community.
If you want a faster answer, talk to an engineer and walk through your architecture directly.
Browse the Scalekit Zapier MCP connector: scalekit.com/connectors/zapiermcp
