Activepieces, the open-source Zapier alternative, now runs an MCP server in every project and also exposes a REST API built for platform administration and embedded deployments. The two overlap on flows and runs. They differ on who the agent is acting as, which project it can reach, and what happens when you run your own instance. This guide compares what each path lets an agent do, the opposite identity models they carry, and how to run either across many customer projects in production.
Your agent needs to work with your users' automations: draft a flow from a sentence, explain why last night's run failed, retry it from the failed step, or switch off a flow that's spamming a Slack channel. Activepieces is the open-source Zapier alternative that keeps coming up in these conversations. Its Community Edition is MIT-licensed, it runs on Activepieces Cloud or on your own infrastructure, and it now ships an MCP server in every project. It also has a REST API built for platform administration and embedded deployments. The two overlap on flows and runs. They differ on who the agent is acting as, which project it can reach, and what happens when you run your own instance. Here's how to pick.
Activepieces runs a Model Context Protocol (MCP) server per project. A project admin turns it on under Settings > MCP Server and copies the server URL, which has the form https://<your-instance>/mcp (or https://<your-instance>/<prefix>/mcp behind a reverse proxy). Authentication is OAuth: the client opens a browser on first use, and per the MCP server overview, "all operations are scoped to the authenticated project." The docs give setup steps for Claude.ai custom connectors, Claude Desktop, Cursor, and Windsurf. They don't carry a beta label or a launch date.
The tools reference lists 47 tools. The 21 Discovery tools are read-only and always on: ap_list_flows, ap_flow_structure, ap_research_pieces, ap_search_actions, ap_get_piece_props, ap_list_connections, ap_list_runs, ap_get_run, ap_find_records, and others. The other six categories can be switched on or off per project: Flow Management (ap_create_flow, ap_lock_and_publish, ap_change_flow_status, ap_delete_flow), Flow Building (ap_build_flow, ap_add_step, ap_update_step, ap_update_trigger), Router & Branching, Annotations, Tables, and Testing & Runs (ap_test_flow, ap_test_step, ap_retry_run, ap_run_action). The MCP tools are free, except ap_run_action, which costs one credit per call.
There is a second sense in which Activepieces "does MCP": flows as tools. The MCP piece has a trigger, MCP Tool, that "creates a tool that MCP clients can call to execute this flow," and an action, Reply to MCP Client, that returns the result. So a flow that reads a HubSpot deal, checks a Postgres table, and posts to Slack can become one callable tool.
The REST API lives at https://cloud.activepieces.com/api on Cloud, or at <your-instance>/api when self-hosted. It uses one auth method: an API key generated in the Platform Dashboard and sent as Authorization: Bearer <key>. The docs say API keys are available "only in the Platform and Enterprise editions" at the moment. Endpoint groups cover projects, users, user invitations, project members, connections, global connections, variables, flows, flow runs, folders, templates, git repos, project releases, piece installation, and embedding origins. Every list endpoint uses seek pagination with limit and cursor.
The MCP server is a flow builder's surface. It has everything a person needs to go from "when a Typeform comes in, add a row and ping sales" to a tested, published flow, without opening the canvas. The API is an operator's surface: it provisions projects, moves flows between environments with releases and git, and manages who belongs where. Neither is a superset. Retries, step tests, and tables are MCP-only in the published docs, and tenant administration is API-only.
Building a flow over the raw API is a schema problem. Each step needs a piece name, a piece version, an action name, and an input object whose shape depends on the action. Many inputs are dropdowns whose options depend on the selected connection, such as a Slack channel list that only exists once you know which workspace. Getting one Slack step right means knowing the piece's property schema, resolving the channel ID, and wrapping it in an ADD_ACTION operation that targets the right parent step.
The MCP server does that work for the model. ap_search_actions maps "send a message to a channel" to the correct piece action. ap_get_piece_props returns the input schema. ap_resolve_property_chain resolves up to 10 dependent dropdowns in one call, ap_validate_step_config returns field-level errors before anything is saved, and ap_validate_flow checks structure before ap_lock_and_publish. Writing the schema is the hard part. Not the API call.
The tradeoff: Activepieces owns the tool list, and the project admin decides which categories are switched on. An agent that worked yesterday can lose Flow Building today because someone turned it off in settings.
The MCP server's OAuth flow ties every grant to one user and one project. Whatever that user can see in that project, the agent can see. Nothing outside it. Activepieces doesn't document scopes for the MCP grant, so the controls are the user's project role and the per-project tool category toggles. What the user can't do, the agent can't do.
Self-hosting changes the plumbing, not the model. The OAuth discovery documents live under /.well-known/oauth-*. If your instance sits behind a path prefix, set AP_FRONTEND_URL to the full public URL, and add a proxy rule that forwards host-root /.well-known/oauth-* paths for any MCP client that ignores the WWW-Authenticate header. Claude honors the header. Not every client does, and a missed rule shows up as a client that never reaches the consent screen.
If you embed Activepieces in your own product, there is a third option. Embeddable MCP lets your backend call generateMcpToken() for a 15-minute token scoped to the user's project, or run a full OAuth flow with PKCE: /authorize returns an authRequestId that expires after 10 minutes, /token issues a 15-minute access token and a refresh token, and /revoke ends it. Embedding is an Enterprise feature.
The API key is a platform credential. It is created in the Platform Dashboard, it manages multiple projects, and it carries no user identity. GET /v1/flow-runs requires a projectId, and so does POST /v1/flows. That means the key can reach any project you pass it, and the only thing keeping an agent inside one customer's project is your code choosing the right ID.
The docs don't describe scopes, per-project keys, or expiry for API keys. They also don't offer OAuth for the REST API. For an agent, that adds up to three consequences:
In a multi-tenant B2B agent, MCP gives you an OAuth grant per user, per project, and the direct API gives you a platform key per Activepieces platform. In neither case does the path itself solve storage, rotation, or revocation; those are infrastructure problems regardless of which path you choose.
Activepieces adds a specific edge. If your customers each run their own Activepieces (Cloud accounts or self-hosted instances), you hold one platform key per customer, each of which can do anything on that customer's platform. If they share one platform as projects on your instance, a single key reaches all of them. Either way, a leaked key is an admin compromise, not a user compromise.
Recommended reading: OAuth vs API keys for AI agents
Activepieces hosts the server on Cloud, owns the tool schemas, and maps each tool call to internal operations. You own each user's OAuth grant and refresh token, and the project mapping: one grant reaches one project, and each project has its own MCP server, so a user who works in three projects needs three grants.
You also own the cost model. ap_run_action charges a credit per call, and any flow started by a tool call is billed as a normal flow run. An agent that "just tries the action to see what happens" in a loop spends the customer's credits.
Self-hosting adds one more item. ap_search_actions and ap_search_triggers need tool search: set AP_TOOL_SEARCH_ENABLED=true, provide an OpenAI key through AP_OPENAI_API_KEY or a platform AI provider, and run Postgres with pgvector. Without the key or pgvector, search falls back to keyword matching. The tools keep working, but they match more loosely, and each response reports the active mode. Cloud has semantic search enabled.
You own schemas, pagination, retries, and the key lifecycle. Activepieces doesn't publish REST rate limits. Its limits page covers execution instead: a 10-minute flow run timeout, 1 GB worker memory, 30-day execution data retention, a 25 MB flow run log on Cloud (runs that exceed it end as LOG_SIZE_EXCEEDED), and 10 MB step files. Self-hosted instances override most of these through environment variables such as AP_FLOW_TIMEOUT_SECONDS and AP_MAX_FILE_SIZE_MB.
Starting flows from outside is HTTP, not REST. The Webhook piece gives a flow a unique Catch Webhook URL that accepts any HTTP method, and its Return Response action replies to the caller. Synchronous responses time out at 30 seconds, and payloads cap at 5 MB on Cloud and 25 MB by default when self-hosted. Each webhook URL is a capability with no user attached, so treat it like a secret.
Run monitoring is polling. GET /v1/flow-runs filters by status values such as FAILED, TIMEOUT, MEMORY_LIMIT_EXCEEDED, and QUOTA_EXCEEDED, by createdAfter, and by failedStepName. The published reference has no endpoint for subscribing to run events.
The REST API is at /v1 and changes with Activepieces releases, which ship often. On self-hosted instances, you choose when to upgrade. The MCP tool list changes with the server: the current reference has 47 tools, and Scalekit's connector currently exposes 44 of them. On Cloud, the MCP tool list your agent sees can change between runs. Self-hosted, it changes when you upgrade.
Both paths hand you a credential. Neither hands you a vault. A multi-tenant agent serving 60 customer teams, each with 5 users working in 2 projects, is 600 Activepieces OAuth grants on the MCP path. Each is bound to one user and one project, must be refreshed before expiry, stored encrypted, kept out of logs and LLM context, and removed when the user leaves. On the API path, the same 60 customers are 60 platform keys with no expiry and no scope, or one key for everyone if they share your instance.
The token type differs. The problem doesn't. And the tempting shortcut is worse here than with most tools. One platform API key behind your agent means every user's request runs as the platform, every project is in reach, and a prompt injection that convinces the model to call DELETE on a project has the authority to do it. Shared credentials are a single-user solution. They do not survive a second user.
Scalekit's activepiecesmcp connector handles the OAuth 2.1 flow, Dynamic Client Registration, token storage, and refresh for the MCP path, and a Scalekit custom connector can hold API keys in the token vault for the API path, so the MCP vs API decision doesn't change your auth infrastructure. Your agent passes an identifier; credentials never touch the agent runtime or the LLM context.
Recommended reading: why a token vault matters for AI agent workflows
Scalekit's activepiecesmcp connector is an MCP-path connector. It proxies the Activepieces MCP server and authenticates with OAuth 2.1 using Dynamic Client Registration, so there is no OAuth app to register with Activepieces first. It exposes 44 tools, all named activepiecesmcp_ap_*, covering discovery, flow management and building, branching, notes, tables, and testing and runs. Three tools from Activepieces' current reference are not in the connector's list: ap_list_folders, ap_move_flow_to_folder, and ap_set_project_context. Each connected account works in the project its user authorized.
Create an Activepieces MCP connection in AgentKit > Connections in the Scalekit dashboard. The name you give it is the connection_name your code passes, and the string must match the dashboard exactly. This is the most common integration error. Copy SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET from Developers > API Credentials into .env. In each Activepieces project your users will connect, a project admin must turn on the MCP server and enable the tool categories your agent needs.
get_or_create_connected_account returns the user's connected account. If it is not ACTIVE, get_authorization_link returns the Activepieces OAuth link. The user signs in to Activepieces and approves once. Scalekit stores and refreshes the tokens.
This is not a catalog load. The agent asks for the tools this user's connected account is authorized to call, then narrows them to the six a run-debugging agent needs. Loading all 44 would put activepiecesmcp_ap_delete_flow, activepiecesmcp_ap_delete_table, and activepiecesmcp_ap_build_flow in front of a model whose job is to explain failures. Those tools never reach this model, so it cannot delete a flow while trying to fix one.
The loop runs until the model stops requesting tools. Every call executes with this user's Activepieces grant and sees only the project they authorized.
For pipelines, skip the model. execute_tool runs one tool with a fixed input and returns data plus an execution_id you can log. This job pulls the 20 most recent failed runs in the user's project.
A kill switch is the other common pipeline: when a downstream system reports a flood, disable the flow that's causing it. activepiecesmcp_ap_change_flow_status takes a flowId and a status. The flow ID comes from your config for this customer, resolved once with activepiecesmcp_ap_list_flows.
Scalekit doesn't ship a prebuilt connector for the Activepieces REST API. To call it, create a custom connector with API key auth, a bearer header, and proxy_url set to https://cloud.activepieces.com/api (or your instance's /api root). Each customer's admin enters their platform key once through Scalekit's hosted connect page, and it is stored as that customer's connected account credential. Then make proxied calls with actions.request():
The key never reaches your agent, but it is still a platform-wide credential. Keep projectId in your own config per customer, never in model output.
If your customers run self-hosted Activepieces, their MCP server URL is on their own domain. Treat each instance as its own integration and register it as a custom MCP connector, following the same bring-your-own-connector path.
The activepiecesmcp connector has 44 tools, and seven of them can delete something: flows, steps, branches, tables, records, fields, and notes. At roughly 200 tokens each, the full set is about 8,800 tokens of tool definitions before the agent does any work, and a model choosing between activepiecesmcp_ap_build_flow, activepiecesmcp_ap_create_flow, and activepiecesmcp_ap_add_step picks wrong more often than one choosing among three read tools. A Scalekit virtual MCP server declares exactly which tools an agent role can see across connections, and session tokens keep each run bound to one user's connected accounts. Docs: set up a virtual MCP server.
One server definition serves every user. Before each run, check that the user's accounts are active and mint a short-lived session token scoped to them. Any MCP client that speaks Streamable HTTP can connect; this example uses langchain-mcp-adapters (pip install langchain-mcp-adapters) and passes the token as a Bearer header.
The agent sees four tools instead of 44, and none of them can delete anything. The endpoint is static; the identity is per-user. Activepieces' own per-project toggles work at category level: Discovery is always on, and turning on Testing & Runs for ap_retry_run also turns on ap_run_action. The virtual MCP server draws the line at the individual tool.
Every execute_tool call returns an execution_id, and every execution is attributed to a connected account, which maps to one of your users and one customer. When a customer asks which agent run disabled their invoice flow at 2:14 a.m., the answer is a lookup, not an investigation. Activepieces sees the change arrive under that user's grant, and your execution log shows which agent run and which prompt led there.
A platform API key breaks that chain on the Activepieces side. Every change made with it belongs to the platform, not a person, and audit logs are a paid admin control in Activepieces to begin with. The agent's own execution log becomes the only record of who asked for what.
Recommended reading: audit trails for agent auth
If your agent helps people build, debug, and operate their own automations, from Claude, Cursor, or your product's assistant, use Activepieces MCP. It has the schema-heavy tools (piece search, property resolution, validation, step tests, retries) that would take months to rebuild on the REST API, and every grant is bounded by one user and one project. If your agent provisions tenants, moves flows between environments, or monitors runs across customers with no person in the loop, use the API, and accept that you are holding an admin key on an edition that has one.
Many production agents need both: MCP for the user-facing work, the API for the platform plumbing. Either way, you hold one credential per user or per customer platform, and that's what needs production-grade infrastructure.
Yes, one per project. A project admin turns it on under Settings > MCP Server, and the URL has the form https://<your-instance>/mcp. Authentication is OAuth in the browser, and every operation is scoped to the project the user authorized. It exposes 47 tools in seven categories, with the 21 discovery tools always on and the other categories switchable per project. Separately, any flow that starts with the MCP Tool trigger becomes a tool MCP clients can call.
Platform administration: projects, users, invitations, members, connections, global connections, variables, folders, templates, git sync, and project releases. It is the path for provisioning tenants and moving flows between environments. It authenticates with a platform API key sent as a Bearer token, available only on the Platform and Enterprise editions, that manages every project and carries no user identity.
Because it is an admin credential with reach across every project you pass it. There is no delegation, so actions are attributed to the platform rather than the person who asked; there is no least privilege, so a key that lists runs can also delete projects; and there is no scope or expiry documented. A leaked key is an admin compromise, not a user compromise.
Yes, through MCP and webhooks. The MIT-licensed Community Edition has no API keys, so there is no REST API automation there, but each project's MCP server still works with per-user OAuth, and flows can be started from outside through their Catch Webhook URL or exposed as tools with the MCP Tool trigger.
When you embed Activepieces in your SaaS and provision a project, members, and connections per customer, when a headless monitor queries failed runs across customer projects every few minutes, when flows are promoted between environments through releases or git sync, or when your backend must start a specific flow on an event. Building, debugging, testing, and retrying flows belong on MCP.
The activepiecesmcp connector proxies the Activepieces MCP server with 44 tools and per-user OAuth 2.1 registered through Dynamic Client Registration, so no app registration is needed. Each user authorizes once, Scalekit stores and refreshes the tokens, a virtual MCP server draws the line at the individual tool rather than the category, and every execution returns an execution_id attributed to that user. The REST API's platform key can live in a custom connector alongside it.
Browse the Scalekit Activepieces MCP connector and the Activepieces MCP connector docs with the full tool list. See Scalekit pricing, or talk to us.
