Does Moving to the Conversions API Make Telehealth Tracking Safe?

The most common answer I hear when I ask a telehealth brand about tracking risk is "we moved to CAPI." It's usually said as if it ends the conversation.

It doesn't. Moving to Meta's Conversions API changes who sends the data. Your server sends it instead of the visitor's browser. It doesn't change what gets sent. A server that forwards everything the browser had is a pixel with extra steps.

This matters more this fall than it did a year ago.

Why this question is back

The FTC's complaint against Hims & Hers, filed in July with Utah and Los Angeles County, alleges that health information reached advertising platforms through several routes. IAPP's analysis of the complaint points out that one of those routes is the Conversions API, Meta's server-side tracking infrastructure, and argues that the same disclosure concerns apply to it as to the pixel. Customer-list uploads are in there too.

On October 22, Hims asked the court to dismiss the case. According to reporting on the motion, Hims argues its privacy policy disclosed sharing with marketing and advertising partners, and that words like "private" and "discreet" described the convenience of online care, not a promise. These are allegations and arguments. Nothing has been decided.

For a media buyer, the takeaway doesn't depend on how the case ends. The complaint lists the server-side route right next to the pixel, not as a separate, safer category. Meta draws the same line: its health and wellness restrictions apply to both the Meta Pixel and the Conversions API.

What CAPI actually changes

To be fair to CAPI, it changes some important things:

• You decide what leaves. A browser pixel collects what the page exposes. A server event contains only what your code puts in it. That's real control, but only if you use it.
• Third-party scripts stop running on sensitive pages. If you remove the pixel from intake and checkout and send server events instead, Meta's JavaScript no longer runs on those pages.
• You can send events from your backend. Outcomes that happen after checkout, like a provider approving an order, never happen in a browser. CAPI is the only way to send them.

What it doesn't change: Meta still receives whatever you put in the payload, along with identifiers that tie it to a person. That's the part that matters.

Where condition data sneaks into a server event

Most server-side setups I look at were built to match the pixel, which means they faithfully copy the pixel's problems. Here are the fields to check.

event_source_url. Meta's documentation says this field is required for website events sent through the Conversions API, and that it should be the browser URL where the event happened. If your intake flow lives at /weight-loss/intake/step-3, that path goes to Meta with every event unless you change it. Query strings are worse. They can carry quiz answers, product IDs and campaign names.

referrer_url. It's optional, but check whether your integration fills it in. It's the previous page, which in a telehealth funnel is often the treatment page.

custom_data. This is where content_name, content_category, contents and any custom fields go. Plugins love to fill it with product titles. "Semaglutide 3-Month Plan" is a product title and a health fact.

value. An exact value that matches a single treatment's price can tell Meta what was bought, even when every other field is clean.

user_data. Hashed email, phone and external IDs are what make the event about a specific person. Hashing makes matching possible. It doesn't make the event anonymous.

Customer lists. This isn't CAPI, but it's often set up by the same people. A custom audience built from "everyone who bought a weight-loss plan" tells Meta something about every person on the list.

A 30-minute check you can run today

You don't need new tools for a first pass. You need to look at real payloads instead of trusting the setup screen.

1. Get a raw outbound event. In Events Manager, open Test Events and trigger a test conversion, or ask whoever owns the server integration to log one full request body. The setup UI shows what's configured. The raw body shows what's actually sent.
2. Read every URL field. Check event_source_url and referrer_url. If either contains a condition, product or treatment word in the path or query string, it needs to be rewritten to something neutral before it's sent.
3. Read custom_data line by line. Remove product names, categories, quiz fields and anything a plugin added that you didn't choose. Keep only what you can explain to a client's lawyer in one sentence.
4. Look at the value. If it maps one-to-one to a treatment price, consider sending a value band or a projected value instead.
5. Check deduplication. If you run the pixel and CAPI together, Meta matches them on event_name plus event_id within 48 hours, per Pixel ID. If the IDs don't match, you're double-counting. If you removed the pixel from sensitive pages, make sure the server isn't still sending the same events in the same detail.
6. Check the GTM server container or vendor. If a tag manager or vendor builds the payload, confirm which fields it adds by default. "We turned it on" is the most common reason nobody knows what's in it.
7. Write it down. Keep one page per client listing which events go to Meta, which fields they carry, and why. If someone later compares the privacy policy with the data, you want this page to exist.

Allowlist, not blocklist

The approach that holds up is an allowlist. Decide what each event may contain and drop everything else, instead of trying to list every sensitive thing that might show up. Blocklists fail quietly. Someone adds a new product, a new quiz or a new plugin, and the new field goes straight through because nobody thought to block it.

An allowlisted event for a telehealth checkout might be:

• event_name: a neutral business event, such as Qualified
• event_source_url: the domain only
• value: a projected value band, not the treatment price
• user_data: the hashed identifiers you've decided to send
• nothing else

It's less data than most setups send today. It's also data that tells Meta what it needs to optimize without telling it about anyone's health.

Where Kalman fits

This is how Kalman is built. Every outbound field has to be explicitly allowed by an allowlist firewall. Anything that isn't on the list is dropped, including fields someone adds later. You preview every event before it goes live, and every outbound event is logged, so you can see exactly what was sent to Meta and when. We sign a BAA with every customer.

If your client says "we're on CAPI, we're fine," find out what's in the payload first. Start with a free scan of the site to see which trackers load today and which pages look risky.

This post is general information, not legal advice. The allegations in the FTC's complaint have not been proven, and Hims disputes them.

Sources

• iapp.org
• ftc.gov
• stocktwits.com
• customerlabs.com
• developers.facebook.com
• developers.facebook.com