GTM Unified API: Bring Your Own Enrichment Key and Stop Paying Twice

A GTM unified API that supports bring your own enrichment key passes your existing Apollo, ZoomInfo, or Cognism credentials directly to the underlying data call. You pay your data vendor at the rate you already negotiated, and the orchestration layer charges only for workflow logic on top, not a resale markup on each enriched contact.

Most operators are paying for the same enrichment data twice. The workflow platform they use to run sequences, trigger enrichment, and write to their CRM holds its own master vendor account and resells access through its internal credit system. The data vendor bills the platform; the platform bills you at a markup you cannot audit. Passing your own key removes that middle layer entirely.

What bring your own enrichment key means for your stack

When an orchestration platform sells you enrichment credits, it acts as a reseller. It holds a master Apollo or ZoomInfo contract, charges you a per-credit rate that covers its margin, and your contract is with the platform rather than the data vendor. You have no visibility into the underlying usage, no ability to negotiate a direct volume rate, and no portability if you switch platforms.

Bring your own key reverses this. You hold an API contract directly with Apollo, ZoomInfo, Cognism, or whichever provider covers your ICP. The GTM orchestration layer reads your credential from a secure vault and passes it as the authorization header on every enrichment call. The data vendor bills you. The orchestration platform charges nothing for the data lookup.

The practical result for a team already on Apollo's Professional plan at $79 per user per month is that enrichment calls run against Apollo's full database through the unified API at no additional per-contact cost beyond the seat. Apollo still enforces its own API rate limits and credit rules. The orchestration layer becomes the caller, not the reseller.

The waterfall enrichment guide covers how this works when you layer multiple providers in a cascade. The BYOK logic applies at each layer: each provider receives your own key, each vendor bills you directly, and the orchestration handles routing and deduplication without touching either credit pool.

Which enrichment providers you can wire directly in 2026

Apollo

Apollo is the most common key operators bring. It exposes contact search, people enrichment, and company enrichment through a REST API. You generate the key in Apollo's developer settings, store it in the GTM API's credential vault, and the orchestration layer calls Apollo's endpoints with your key. Your Apollo seat credit pool depletes at the normal rate. Apollo's API access is available on paid plans, with higher rate limits on Professional and Organization tiers.

ZoomInfo

ZoomInfo API access requires a specific API add-on to your contract rather than being included in standard seats. If your team has the API-enabled tier, the key works the same way as Apollo. If not, bringing your own ZoomInfo key means negotiating API entitlement in your next renewal conversation. ZoomInfo's median annual contract runs near $31,875 per year based on 1,300 verified purchases tracked by Vendr, so the API add-on cost needs to clear a real volume threshold to justify BYOK over a managed waterfall alternative.

Cognism

Cognism gives API access on Business plans and above. Coverage is strongest on European contacts, which is where Cognism's GDPR-compliant dataset justifies the per-contact cost over Apollo's weaker EU coverage. If your ICP sits in UK, DACH, or Nordics, Cognism as your BYOK layer often outperforms Apollo on raw coverage, which changes the layering order in a cascade.

Crustdata

Crustdata is API-first by design, so the key concept is built into its entire model. It is the operator default when the calling system is an agent rather than a human clicking a UI, because the response shape is built for programmatic consumption. People Data Labs follows the same pattern. Both work well as a specialist layer inside a bring your own key waterfall when your primary database falls short on certain segments.

FullEnrich

FullEnrich exposes its own API, which internally cascades through 15 or more underlying providers per request and charges only on verified hits. Using FullEnrich as a BYOK layer means you bring one key and get a managed waterfall underneath it. The per-result pricing runs roughly 1 credit per verified work email, 3 credits per personal email, and 10 credits per mobile phone, with pricing and credit details on the FullEnrich pricing page. In an operator stack, FullEnrich typically sits as the fallback layer after Apollo, handling the rows Apollo could not find.

Clearbit

Clearbit's standalone API still works for existing API customers, but HubSpot stopped accepting new independent Clearbit API signups after the acquisition closed in December 2023. New teams looking for "Clearbit data" are directed to HubSpot's Breeze Intelligence product, which requires an active HubSpot CRM contract. If your team has an existing Clearbit API key, it remains valid for BYOK setups. Teams without one should evaluate Apollo or Crustdata as the current direct API replacement, since the underlying dataset quality for B2B email and company data has largely moved to those providers.

The real cost of not using your own key

Orchestration platforms that resell enrichment typically build their credit economics so they earn margin on every data lookup. The exact conversion between "platform credits" and "underlying API calls" is usually not published, which means you cannot compare your effective per-contact enrichment cost against what direct API access would run on the same data.

The gap only becomes visible when you instrument it yourself. Take a team running 10,000 enrichments per month against Apollo data through a platform's credit system. On Apollo's Professional plan, the enrichment API is included with the seat, subject to plan-level rate limits. The same 10,000 contacts enriched via Apollo's own API costs whatever the seat fee covers. Running them through a platform reselling Apollo calls at a markup costs more per contact for the same underlying data, and the gap widens every month at volume.

FullEnrich's published research on waterfall enrichment puts single-source email match rates at 40 to 60 percent of a B2B list. If you are paying enrichment markup on the 40 to 60 percent that finds nothing, you are paying twice for the same misses. BYOK with a true waterfall underneath means you pay the data vendor only on verified hits, and the platform takes no cut on the lookups that failed.

The best lead enrichment tools in 2026 maps provider pricing layer by layer if you want to model the comparison for your own monthly volume before committing to a setup.

How to connect your Apollo or ZoomInfo key to a GTM unified API

The mechanics are consistent across unified API setups that support BYOK enrichment.

First, generate an API key from your data vendor's developer console. For Apollo, that is under Settings in the Apollo dashboard, in the Integrations or API section. For ZoomInfo, API access sits in the developer portal but requires API add-on entitlement confirmed in your account. For Cognism, the key is in the API section of your account settings.

Second, store the key in the GTM platform's credential vault rather than as a plain text config variable. A credential vault encrypts at rest and injects the key at call time without exposing it in workflow logs or run outputs. Most operators skip this step by pasting keys into workflow fields directly, which creates a rotation and audit problem that surfaces at the worst time, usually after a team member leaves.

Third, specify the provider routing rule in the enrichment workflow. The unified API needs to know that when a workflow step calls "enrich person by email," it should route that call through Apollo with your key rather than through a platform-owned account. This routing rule is typically set once per key per workflow, not configured per run.

Fourth, set your own rate limit caps in the orchestration config to stay inside the data vendor's limits. Apollo's API enforces per-minute and per-day call limits that vary by plan tier. If the orchestration layer runs a bulk enrichment job faster than Apollo allows, the result is 429 rate limit errors, retries, and delayed runs. The cap goes in your orchestration config before you run any production batch.

The Yalc GTM AI agents hub shows how enrichment wires as one step inside a multi-action agent, with BYOK credential routing handled at the platform layer so individual workflow configs never hold the key directly.

When bring your own key saves money and when it does not

BYOK enrichment is worth the setup when two conditions hold: you already have a direct vendor subscription with API access included, and your monthly enrichment volume is high enough that the platform margin is a real budget line.

The practical break-even sits around 5,000 enrichments per month for most operator setups. Below that volume, the time to configure secure key management, set routing rules, and maintain the integration usually costs more than the margin the platform was taking. Above that volume, the saving compounds monthly and typically covers the setup cost within a quarter.

Three cases where BYOK is the wrong call. First, if you do not have a direct vendor subscription yet, adding one to capture a saving means you absorb a new contract, onboarding, and negotiation overhead that erases the benefit in the early months. Second, if your provider does not offer full API access on your current tier, BYOK is not available without upgrading, and the upgrade cost may cancel the saving. Third, if your primary data vendor has weak coverage on your ICP, bringing your own key to a low-hit-rate provider does not solve the coverage problem. A managed waterfall like FullEnrich can deliver better coverage per dollar even at resale pricing when your single-source hit rate sits below 60 percent, because the coverage lift from 55 to 80 percent is worth more than the margin spread.

The decision rule: bring your own key when you have the subscription and the volume. Layer a managed waterfall as a fallback above the direct key, not as a replacement for it.