Your agent needs to read HeyReach campaigns, enroll leads, and watch the LinkedIn inbox for replies. HeyReach ships both an official MCP server and a public REST API, so the obvious question is which one to build against.
For most tools in this series, that question resolves along a clean line: MCP gives you per-user OAuth, the API gives you a service credential. HeyReach does not split that way. Both paths run on the same class of static key. The interesting tradeoffs are somewhere else entirely.
These are two front doors onto the same backend. Understanding how each one is credentialed matters more than understanding what each one is called.
HeyReach was among the first LinkedIn outreach platforms to ship an official MCP server, documented on the HeyReach MCP product page. It is a remote server, not a local process.
Each workspace gets its own MCP Connection URL and MCP Key, generated under Integrations and then HeyReach MCP Server. Regenerating the key rewrites the Connection URL. Clients that only speak stdio bridge to it through mcp-remote, per HeyReach's Claude integration guide.
The REST API is documented in the HeyReach API Postman collection. The base path is https://api.heyreach.io/api/public.
Authentication is a single X-API-KEY request header on every call. HeyReach states that API keys never expire, though they can be deleted or deactivated, and that the key maps requests to your organization. You can validate a key with a GET against /auth/CheckApiKey.
Capability comparison usually starts with two published tool lists. For HeyReach, only one side publishes anything, so it is worth being precise about what is verifiable and what is not.
HeyReach's help center carries six articles covering MCP, the API, and webhooks. None of them enumerates the tools the MCP server exposes. The product page describes outcomes such as pulling live stats and pushing qualified leads into a sequence, not tool names or input schemas.
The API side is better, but not by as much as you would like. The Postman collection documents the endpoints; there is no OpenAPI document served from the public host that an agent planner or codegen step could consume.
You cannot plan a HeyReach agent's tool surface from documentation alone. On the MCP path, the only authoritative enumeration is a live tools/list call against your own Connection URL. Treat anything else as hearsay.
This is a real cost. It means your capability audit is a runtime activity, it has to be repeated after HeyReach ships changes, and it cannot be pinned in a spec file that your CI checks against.
If you want a documented, versioned, schema-complete tool list for HeyReach today, the Scalekit HeyReach connector docs publish one. Ten tools, each with typed parameters:
With the enumeration caveat stated, the two paths still differ on properties you can verify from official documentation.
Two rows carry most of the weight. The first is event subscriptions. MCP tool calls are request and response; there is no push. Any agent that reacts to a reply the moment it lands needs HeyReach webhooks, which live outside the MCP surface entirely.
The second is the shared rate limit. Three hundred requests per minute sounds generous until an agent paginates a lead list with four thousand entries while a scheduled stats job runs alongside it.
Worth naming the absence: the headless gap does not exist here. On Salesforce or Slack, MCP forces an interactive OAuth flow and blocks background agents. HeyReach's MCP key is static, so a nightly job can hold it as easily as a chat client can. That is convenient, and it is exactly why the credential question gets harder rather than easier.
Both paths hand your agent a bearer-equivalent secret with full workspace reach. The difference is where the secret sits, and where it leaks.
The MCP Key travels inside the Connection URL. That is why setup is a copy and paste, and it is also why the credential ends up in places you did not choose.
URLs get written to claude_desktop_config.json and equivalents. They get logged by forward proxies. They appear in shell history when someone tests with curl. A header-borne secret is redacted by convention in most tooling; a path-borne secret usually is not.
X-API-KEY is the better shape for the same secret. It stays out of URLs and request lines, and most logging middleware already knows to strip it.
The key itself is no weaker and no stronger. HeyReach documents it as non-expiring, which means the only lifecycle event is manual deletion. As explored in OAuth vs API keys for AI agents, static, non-expiring credentials are a structural liability in production systems.
Across this series the structural point has been that MCP gives you a token per user while direct API calls give you a credential per user, and that neither solves storage, rotation, or revocation. HeyReach breaks the first half of that sentence.
Neither path produces per-user identity. There is no consent flow, no scope, and no way for HeyReach to distinguish which of your users triggered a call. Every action arrives at HeyReach as the workspace. What the user can and cannot do stops being enforceable by the provider, which means it becomes your problem.
Choosing a path does not change the operational load much. Both leave the same four things on your side of the line.
Three hundred requests per minute is a single pool. Your agent, your existing Zapier scenarios, and any human-facing integration draw from it together, and exceeding it returns 429.
Agentic workflows issue several sequential calls per user action. Pagination on heyreach_get_conversations or heyreach_get_leads_from_list compounds that quickly, since HeyReach's own defaults can return payloads in the hundreds of kilobytes. Cap your limits explicitly and back off on 429 from day one.
Because keys never expire, rotation only happens when you force it. And because one key serves the entire workspace, rotating it breaks every agent, script, and integration using that workspace at the same moment.
On the MCP path this is worse, because generating a new MCP Key rewrites the Connection URL. Every client holding the old URL has to be reconfigured, not just re-keyed. This is a core example of the credential ownership problem that multi-tenant agent architectures must solve.
When a team member leaves, disabling their identity provider account does nothing to a HeyReach key that was minted eight months ago and pasted into a config file. There is no OAuth grant for your identity provider to cascade into.
The agent does not decide to keep using that credential. It just does.
HeyReach can add, rename, or change MCP tools without a versioned manifest for you to diff against. Your only detection mechanism is a tools/list call in CI that compares against a checked-in snapshot. Build that before you need it.
The choice is narrower than usual here, because the auth models converge. It comes down to who is driving and what has to happen in real time.
This is the part that determines whether your HeyReach agent survives its second customer.
A single HeyReach credential grants full workspace access: launching campaigns, reading inbox conversations, modifying lead lists. There is no read-only variant and no per-tool scope.
In a multi-tenant B2B product, that means an agent acting for one user holds exactly the same reach as an agent acting for anyone else in that workspace. Attribution collapses. Your audit trail says the workspace did it, which is not an answer a security reviewer accepts. This is precisely why access control for multi-tenant AI agents requires a layer above whatever the provider exposes.
Storage that is encrypted at rest and isolated per tenant. Resolution that fetches the right credential server-side so it never enters the agent runtime or the LLM context. Revocation that fails closed for one user without breaking the others. Logging that ties every tool call back to the human who authorized it.
None of that is on either HeyReach path. The token type is identical; the infrastructure is identical; the work is identical.
Scalekit's HeyReach connector is API key based, matching how HeyReach actually authenticates. What it adds is the per-user layer HeyReach does not have.
Create the connection once in the Scalekit dashboard, then attach each user's HeyReach key to their identifier. The connectionName string must match the connection name configured in your dashboard exactly; this is the single most common integration error.
There is no redirect and no consent screen, because HeyReach has neither. The key is vaulted from this point forward.
The agent does not load a connector catalog. It loads the tools this user's connected account is authorized to call, then runs the tool-calling loop against that surface.
The HeyReach key is resolved server-side on each call. It never reaches the agent process and never enters the model's context. This pattern is central to secure token management for AI agents at scale.
Because HeyReach's surface is not fully enumerable, you will eventually need an endpoint that has no prebuilt tool. The proxy path uses the same vaulted credential.
A HeyReach outreach agent rarely touches only HeyReach. It reads a CRM, drafts in a doc, and posts to Slack. That is where per-user isolation and tool scoping stop being nice to have.
A Virtual MCP server declares exactly which connections and which tools an agent can see. You create it once per role, not once per user, and you get a static mcp_server_url back.
A triage agent that only reads should not be able to call heyreach_add_leads_to_campaign. Here it cannot, because the tool is not on its server.
The endpoint is static. The identity is not. Before each run, confirm the user's connections are live, then mint a short-lived token bound to that user.
HeyReach's own MCP endpoint is one static URL per workspace with one static key inside it. Sharing that across users means sharing everything.
A Virtual MCP server inverts it: one definition, a per-run token scoped to one user's connected accounts, and a tool list you chose deliberately. Trimming a forty-tool context down to five also removes roughly eight thousand tokens of overhead before the agent does any work. Surface reduction is the lever.
Outreach agents send messages to real prospects from real LinkedIn accounts. When something goes wrong, "which agent did this, for whom, and was it authorized" is not an academic question. Agent tool observability is what separates a system you can debug from one you can only restart.
Nothing useful. Every call arrives at HeyReach carrying the same organization-mapped credential. There is no sub, no acting party, and no consent record to point at.
If an agent enrolls the wrong two hundred leads, HeyReach's side of the story is that the workspace did it.
Scalekit resolves the credential per user and logs the call. Every HeyReach tool invocation is attributed to the identifier that authorized it, retained for 90 days, and exportable to your SIEM, as described on the Scalekit HeyReach connector page.
That turns the question into a query. It also satisfies the audit-trail requirement your enterprise customers will raise long before they raise anything else about your agent. A proper audit trail for agent auth is a non-negotiable baseline for B2B SaaS.
If a human is sitting in an MCP client and the work is exploratory, use HeyReach's MCP server. It is the fastest route to a working tool surface, and per-workspace Connection URLs are a reasonable isolation boundary for agency work.
If your agent runs unattended, needs webhook-driven reactions, or has to survive a schema change without an incident, build against the API and control your own pagination and backoff.
What does not change is the credential. Both paths hand you one static, non-expiring, workspace-wide key with no scopes and no user identity attached. Everything that makes that safe for a second customer is infrastructure you build or buy.
Building a HeyReach agent and want a second opinion on the auth model? Join the Scalekit community on Slack, or talk to an engineer if you need help now.
Browse the Scalekit HeyReach connector or read the HeyReach connector docs.
