Connecting an app to ZoomInfo's MCP server means picking how it authenticates. The choice looks like plumbing, but it decides something real: whether your app can tell who is asking. One flow signs in each user. The other runs as a single service account for everyone.
ZoomInfo supports two OAuth flows. One is user sign-in: each person logs in with their own ZoomInfo account (the Authorization Code with PKCE flow). The other is a service account: the app authenticates once as itself (the Client Credentials flow), and no individual signs in.
The Short Version
Use user sign-in for anything where the answer depends on who's asking, which covers most agent and copilot work. A service account fits when one shared identity is fine: a background job, or an internal app where you don't want every user to sign in. ZoomInfo is valuable through either flow. We recommend user sign-in wherever it's practical, because it adds per-user context on top of the company-level intelligence both flows provide.
How They Differ
| User sign-in | Service account | |
|---|---|---|
| Who authenticates | Each user, with their own ZoomInfo login | The app, as one integration user |
| User-level context | Yes: meetings, renewals, CRM ownership, saved ICP, call signals | None; one shared identity for everyone |
| Attribution and permissions | Per user, respecting each person's entitlements | Every action runs as the integration user |
| Setup friction | Each user signs in once | No per-user sign-in |
| Best for | Agents and copilots where the answer depends on the user | Background jobs, or an internal app that serves many users through one connection |
Why User-Level Context Matters
A lot of what makes ZoomInfo useful inside an agent is personal. Consider three requests a rep might make. "Research the accounts I'm meeting with this week" needs that rep's calendar. "Show me my upcoming renewals and any recent pain points they've mentioned on calls" needs their book of business and their call recordings. "Find 10 new accounts that match my ICP that I don't already own in the CRM" needs their saved ICP and their CRM ownership.
Each one resolves against a specific person, and ZoomInfo assembles that context on the server side from the signed-in user's models. With a service account there is no signed-in user, so there is nothing to resolve against. These requests either fail or fall back to a generic answer. The data is all still there. The app just has no way to say whose meetings, whose renewals, or whose accounts you mean.
What a Service Account Is Good At
A service account earns its place in two situations. The first is back-office work. A nightly job that enriches new CRM records, or a pipeline that syncs firmographics into a warehouse, has no person in the loop and no reason to ask for one.
The second is an internal application where you'd rather not make every user authenticate. One connection bridges your app and ZoomInfo, and anyone on the team can run GTM queries through it without a sign-in of their own. When a single point of entry matters more than per-user personalization, that's a deliberate, reasonable choice.
Just be clear about the tradeoff. Every call runs as one integration user, so there is no "my meetings" or "my accounts," because there is no "me." You still get ZoomInfo's company-level intelligence for everyone. What you give up is the per-user context behind requests like the ones above.
Choosing
Map it to the work:
- Does the answer depend on who's asking (an agent or copilot a rep drives in the moment)? Use user sign-in.
- Is one shared identity acceptable (a background process, or an internal app where a single sign-in beats per-user logins)? A service account is fine.
If a feature could go either way, default to user sign-in. The sign-in is a one-time step, and it adds per-user answers on top of the company-level intelligence the app would have anyway.
Setting It Up
You act on this choice when you set up your app, and where you do that depends on your account. Existing ZoomInfo customers register apps in the Developer Portal. If you signed up through gtm.ai, you'll use the API/MCP tab in your workspace instead. Both produce an app with the credentials your client or code connects with.
How to Build Your Own App on the ZoomInfo MCP walks through both paths step by step, and is the place to go once you've decided. For the request and response details of each flow, see ZoomInfo's user sign-in↗ and service-account↗ references.