Is the Meta Conversions API (CAPI) HIPAA Compliant?

Last updated: October 6, 2026 · By Jason Garrett, Founder, Coast Studio. Not legal advice. Full legal landscape: The State of HIPAA Tracking.

Not by itself — Meta still doesn't sign BAAs, so nothing about CAPI is inherently HIPAA compliant. But CAPI is the mechanism that makes compliant Meta advertising possible, because unlike the pixel, it puts you in control of every field that leaves your infrastructure. The pixel broadcasts whatever the browser sees; CAPI sends only what your server chooses to send. Compliance lives in that choice.

Since July 2026 that is a matter of public record. The FTC, California, and Utah named the Conversions API alongside the Meta pixel in their complaint against Hims & Hers, treating both as means by which health information reached Meta. The transport earned Hims nothing, because the payload carried the condition either way.

The distinction that matters

A client-side pixel is a firehose you can't filter: URLs, titles, click data, and identifiers flow to Meta from the visitor's browser. CAPI inverts the model — events go first to your server (or a gateway you control), where they can be inspected, stripped, and minimized before anything reaches Meta.

That inversion is the whole game. It's why "we replaced the pixel with CAPI" can be either a genuine compliance fix or a cosmetic one, depending entirely on what your implementation forwards. A naive CAPI setup that relays full page URLs and un-consented identifiers has the pixel's problems with extra steps.

The FTC has now named CAPI

Before July 2026, the argument above was ours to make. Now a filed complaint makes it: FTC, People of the State of California, and Utah Division of Consumer Protection v. Hims & Hers Health, Inc., No. 3:26-cv-07871-VC (N.D. Cal.).

The complaint describes both tools in one breath — the pixel as embedded code, and the Conversions API as “another Meta tracking tool that serves the same purpose … but operates differently to the extent it creates a direct connection between the advertiser’s server … and Meta’s systems.” Then it alleges what the events carried:

• Roughly 8 million Complete Registration and Purchase events reached Meta through the two tools.
• Each event paired an identifier — email address, IP address — with a custom parameter naming the treatment. One was product_bucket carrying "M-R" for mental health, alongside code names the complaint says Meta could already read.
• Separately, 14 million email addresses went up as Customer List Custom Audiences, and Meta matched about 10 million of them to a user ID.

The lesson is narrow. The fields decided the exposure, and the transport was incidental. A gateway you control earns its keep only when you use the control: strip the condition, keep the conversion.

These are allegations. Hims has called the claims baseless and is defending the case. The value here is the regulator’s stated theory, which holds whatever the outcome. Fuller context: The State of HIPAA Tracking.

What a defensible CAPI implementation looks like

1. A server-side gateway you control — server-side GTM in your own cloud environment, or a purpose-built healthcare gateway like Curve, which exists precisely to scrub PHI from ad-platform event streams.
2. PHI scrubbing as a hard rule, not a habit: no health-revealing URLs, page titles, form values, or custom parameters. Event name, timestamp, and value only.
3. Identifiers only with consent: hashed emails/phones flow only for users whose separate, logged consent covers sharing — MHMDA's standard, which is the strictest you'll face nationally.
4. Data minimization by default: send the least Meta needs to optimize. Match quality scores are not a compliance KPI.
5. Documentation: the scrubbing config, the consent log, and a data map. In litigation, provable architecture is the difference between a nuisance letter and a settlement.

Running Google Ads as well? Google splits from Meta on hashed identifiers. See what you can send to Meta CAPI and Google offline conversions, field by field.

Does stripping all that data kill performance?

No — and this surprises people. Server-side events survive ad blockers, Safari's tracking prevention, and cookie decay that silently eat 20-40% of client-side pixel events. Most healthcare accounts we've migrated see equal or better event volume and ROAS after the move, with optimization running on clean conversion counts rather than granular (and radioactive) behavioral detail.

FAQ

Is CAPI a substitute for a BAA with Meta? No. There is no BAA with Meta, which is why nothing identifying a patient and their health status can be sent — with or without CAPI. The architecture works by ensuring what reaches Meta isn't PHI in the first place.

Can I run the pixel and CAPI together like Meta recommends? Meta's "redundant setup" advice is written for e-commerce, not healthcare. Running the pixel alongside CAPI reintroduces exactly the client-side leak you were fixing. Healthcare setups should be CAPI-only.

Does moving to server-side tracking make us compliant? By itself, no. The Hims complaint names the Conversions API alongside the pixel, so a server-side path carrying the same payload carries the same exposure. Server-side is worth building because it gives you one place to strip fields. The stripping is the compliance.

Do I need a vendor, or can we build this ourselves? Self-managed server-side GTM works if you have the engineering discipline to maintain scrubbing rules forever. Purpose-built gateways cost money but make the scrubbing a product guarantee instead of a tribal-knowledge script. We implement both; the right answer depends on your team.

Want the migration done right? This is a core Coast Studio build.