What Is Conversion API (CAPI)? Healthcare Implementation Explained

Two healthcare marketing teams want to measure whether their Facebook ads are driving appointment bookings. Both understand that the Meta Pixel creates compliance risk. Both decide to implement Meta's Conversion API instead. Six months later, one team is running compliant campaigns with full attribution. The other is transmitting patient email addresses, phone numbers, and appointment types to Meta's servers with every conversion event.

The difference is not the technology. Both teams are using CAPI. The difference is the architecture between their website and Meta's API endpoint.

Conversion API is a server-to-server interface that lets you send conversion events to ad platforms without using browser-based tracking pixels. Meta, Google, TikTok, LinkedIn, and other platforms all offer their own versions. The concept is the same across all of them: instead of JavaScript in the visitor's browser sending data directly to the ad platform, your server sends the data through an API call.

For healthcare organizations, CAPI solves one problem and creates another. It eliminates the uncontrolled browser-to-third-party data flow that has driven $193 million in enforcement actions. But a standard CAPI implementation, following the platform's default setup guide, still sends personally identifiable information and health context to the ad platform. The server-to-server channel is more controllable than a pixel, but it is not automatically compliant.

Pixel vs. CAPI: Where the Data Travels

Understanding why CAPI matters for healthcare requires seeing how it differs from pixel-based tracking at the data flow level.

With a tracking pixel, the visitor's browser loads JavaScript from the ad platform. That JavaScript collects data (IP address, page URL, cookies, form inputs, click events) and sends it directly to the platform's servers. The healthcare organization never sees the data in transit. There is no opportunity to filter, redact, or review what the pixel transmits. This is the architecture behind the Kaiser Permanente case, where tracking code transmitted health information to Google, Microsoft, Meta, and X across 13.4 million members for seven years without member consent.

With a Conversion API, the data flow changes. The visitor's browser sends event data to your server (or a server you control). Your server then makes an API call to the ad platform, sending only the data you choose to include. The visitor's browser never communicates with the ad platform directly.

This is a meaningful architectural improvement. But the critical word is "choose." By default, the ad platforms' CAPI documentation instructs you to send as many user parameters as possible: email addresses, phone numbers, names, dates of birth, IP addresses, and user agent strings. Meta's documentation explicitly encourages sending hashed email and phone number for "better match rates." Google's server-side tagging documentation recommends forwarding the full user data layer.

For a retail company, following these instructions is fine. For a healthcare organization, following them creates the same PHI exposure that pixels create, just through a different channel.

The Standard Setup Trap

Most CAPI implementation guides, including official documentation from Meta and Google, describe a setup that looks like this:

1. Install a server-side tag manager or gateway

2. Capture user events (page views, form submissions, button clicks)

3. Forward those events to the ad platform API with user matching parameters

4. The ad platform matches the event to a user profile for attribution

Step 3 is where healthcare implementations diverge from standard ones. In a typical setup, the server forwards the full event payload: the user's hashed email, hashed phone number, the event name ("appointment_booked"), the page URL ("/services/cardiology/schedule"), and additional parameters like appointment type or service category.

In healthcare, this payload contains PHI. A hashed email address is still an identifier (hashing is not anonymization; it is a consistent transformation that can be reversed or matched). The event name reveals a health action. The page URL reveals a health interest. The combination identifies a specific person engaging with specific health services.

The GoodRx enforcement illustrates this problem. GoodRx configured tracking that shared prescription drug names, health conditions, and personal identifiers with Facebook, Google, and other ad platforms. The mechanism was client-side pixels, but the data payload is identical to what a naive CAPI implementation would send: user identifiers paired with health context.

Healthcare-Grade CAPI Architecture

A compliant CAPI implementation for healthcare requires a layer between your website and the ad platform's API. This layer serves three functions: stripping identifiable information, removing health context from event data, and gating all data transmission on verified consent.

Identifier management. Instead of forwarding hashed patient email addresses or phone numbers to ad platforms, a compliant implementation uses non-reversible, non-matchable identifiers or omits user matching parameters entirely. Some healthcare organizations use synthetic conversion events that confirm an action occurred without identifying who performed it. Others use aggregate conversion data reported daily rather than per-event. The right approach depends on your measurement needs and risk tolerance.

Event sanitization. Event names like "appointment_booked" or "consultation_requested" carry health context when fired from a cardiology page or a mental health services section. A compliant implementation strips health-specific context from events before they reach the API. This might mean standardizing all events to generic names ("form_submitted" rather than "appointment_booked_cardiology"), removing page URL parameters that reveal health categories, and excluding any custom data fields that reference services, conditions, or departments.

Server-side consent gating. Before your server sends any event to any ad platform API, it must verify that the visitor has provided consent. This verification must happen on your server, not in the browser. Client-side consent checks can be circumvented by script timing issues, and they cannot guarantee that data is held back until consent is confirmed. Server-side consent enforcement ensures that no API call fires until consent is verified. This is increasingly important as state health privacy laws expand consent requirements beyond what HIPAA alone demands.

The CDP as the Compliance Layer

The most practical way to implement healthcare-grade CAPI is through a HIPAA-compliant CDP that sits between your data collection and the ad platform APIs.

A CDP designed for healthcare acts as the compliance layer automatically. It collects events from your website through first-party, server-side infrastructure. It evaluates each event against your consent policies and data governance rules. It strips or transforms identifiers and health context. Then it forwards the sanitized event to the ad platform's Conversion API.

This approach has several advantages over building a custom CAPI integration.

Centralized control. When you need to update data governance rules, you change them in one place. A custom CAPI integration for each platform means maintaining separate filtering logic for Meta, Google, TikTok, and LinkedIn.

BAA coverage. A HIPAA-compliant CDP signs a comprehensive BAA covering all data it processes. Meta, Google, TikTok, and LinkedIn do not sign BAAs for their advertising products. The CDP is your Business Associate; the ad platforms are not.

Audit trail. A compliant CDP logs every event it processes: what came in, what consent status was evaluated, what was filtered, and what was forwarded. This audit trail is essential for demonstrating compliance and investigating potential issues.

Ongoing monitoring. The CDP can work alongside a web scanner that continuously verifies no client-side tracking code has been reintroduced to your site. Marketing teams, CMS plugins, and third-party integrations can add pixel code at any time. Continuous scanning catches it before it becomes a multi-year exposure.

CAPI Across Platforms: What Each One Requires

Each ad platform has its own version of CAPI, with different terminology and different data requirements.

Meta Conversion API expects events with user data parameters (email, phone, name, IP, user agent) for matching. Healthcare implementations should minimize or eliminate these parameters and accept reduced match rates in exchange for compliance. Meta allows events without user matching parameters; attribution accuracy decreases, but the integration still functions.

Google Ads server-side tagging routes conversion data through a server-side Google Tag Manager container. Healthcare implementations must ensure the server container strips health context and identifiers before forwarding to Google. Google's Enhanced Conversions feature (which sends hashed user data for better matching) requires careful evaluation in healthcare contexts.

TikTok Events API and LinkedIn Conversions API follow similar patterns. Both accept server-to-server conversion events. Both encourage sending user identifiers for matching. Healthcare implementations should apply the same principles: strip identifiers, sanitize events, and gate on consent.

The consistent principle across all platforms: CAPI is a transport mechanism, not a compliance mechanism. The compliance comes from what you do with the data before it enters the API.

FAQ

Is CAPI automatically HIPAA compliant because it is server-side?

No. CAPI changes how data is transported (server-to-server instead of browser-to-third-party), but it does not change what data is transported. A CAPI implementation that sends hashed patient email addresses alongside health-related conversion events creates the same PHI exposure as a pixel. Compliance requires filtering and transforming the data before it reaches the API endpoint.

Do ad platforms sign BAAs for their Conversion APIs?

No. Meta, Google, TikTok, and LinkedIn do not sign Business Associate Agreements for their advertising products, including their Conversion APIs. This means any PHI sent through these APIs has no HIPAA protection on the receiving end. A compliant architecture ensures no PHI reaches the API in the first place.

Will our ad attribution suffer if we remove user matching parameters?

Match rates will decrease when you stop sending hashed emails, phone numbers, and other identifiers. The magnitude depends on the platform and your campaign structure. However, many healthcare organizations find that aggregate conversion reporting, modeled conversions, and platform-side statistical attribution provide sufficient measurement for campaign optimization. The alternative, sending PHI to ad platforms, is not a viable tradeoff.

Can we use Meta's CAPI in "redundant" mode alongside the pixel?

Meta recommends running CAPI alongside the Meta Pixel for better attribution. In healthcare, this defeats the purpose. The pixel reintroduces the direct browser-to-Meta data flow that CAPI was meant to eliminate. Healthcare implementations should use CAPI exclusively, with the pixel fully removed from the site.

What is the difference between CAPI and server-side tracking?

CAPI is a specific type of server-side tracking. "Server-side tracking" is the broader architecture where data collection and routing happen on your servers rather than in the visitor's browser. CAPI refers specifically to the conversion event APIs offered by ad platforms (Meta, Google, TikTok, etc.). A server-side tracking implementation typically includes CAPI as one component alongside server-side analytics, server-side consent management, and other data flows.

CAPI is the right direction for healthcare marketing measurement, but the default implementation instructions from ad platforms are not designed for HIPAA compliance. If your team is implementing Conversion APIs, Ours Privacy provides the server-side infrastructure that ensures no PHI reaches ad platform endpoints while preserving the attribution data your campaigns need.

Related reading:

• What Is a Tracking Pixel? Why Healthcare Websites Should Remove Theirs

• What Is Server-Side Tracking? A Guide for Healthcare Marketers

• Meta Conversion API for Healthcare: Server-Side Setup Without PHI

• What Is Enhanced Conversions? Healthcare Compliance Considerations