The FTC Just Named the Conversions API in a Health Privacy Complaint: Server-Side Is Not a Defense

For roughly three years, the standard answer to healthcare pixel risk has been to move tracking server-side. A complaint filed this week takes that answer apart. In paragraph 70 of the Federal Trade Commission's case against Hims & Hers Health, Inc., the FTC names both the Meta Pixel and the Meta Conversions API. It describes the Conversions API accurately, noting that it operates differently "to the extent it creates a direct connection between the advertiser's server, website, app or other internal software and Meta's systems." Then it pleads that connection as a vector for the alleged disclosure of sensitive health information anyway.

The takeaway is narrow and important. Moving a conversion event from the browser to your server changes who sends the data. It does not change what the data is, who receives it, or whether the person it describes agreed to the transfer. Those are the three things a regulator actually evaluates. Curve is a HIPAA-compliant conversion tracking platform that runs server-side and removes protected health information from conversion events before they leave your infrastructure, so healthcare advertisers can keep measurement without turning it into a disclosure.

None of this means server-side tracking is useless. It is better engineering, and it is the only place a real control can live. The point is narrower: relocating the transport begins a compliance program, it does not finish one.

The case is FTC, the People of the State of California, and the Utah Division of Consumer Protection v. Hims & Hers Health, Inc., Case No. 3:26-cv-7871 in the Northern District of California, and the redacted complaint is public. Everything in it is an allegation. Hims has denied the allegations, says its privacy policy makes clear that users may choose how their data is used, and has said it intends to defend the case.

The Short Version

• Complaint paragraph 70 names the Meta Pixel and the Meta Conversions API together, characterizes the Conversions API correctly as a server-to-server connection, and pleads it as an alleged disclosure channel anyway.
• Paragraph 77 names two more server-side vectors, a Google Ads S2S pixel and TikTok s2s, so the pleading is not a drafting accident.
• A regulator's test is payload and permission, not plumbing: what arrived, was it identifiable, and did the consumer agree given what they were promised.
• Most Conversions API migrations increase identifiability, because advanced matching parameters are the main reason teams adopt the API at all.
• Server-side is still the right architecture. It is the only layer where redaction can be enforced rather than attempted, which is exactly why it has to perform redaction to count for anything.
• The audit question is no longer "is it server-side." It is "show me the field-level payload that left our infrastructure last Tuesday."

What Paragraph 70 Actually Says, and Why the Wording Matters

The striking thing about paragraph 70 is how well the FTC understands the technology. The complaint does not confuse the Conversions API with a browser tag. It distinguishes it, describing an integration that creates a direct connection between the advertiser's own systems and Meta's. That is a fair description of what the Conversions API is.

Having drawn the distinction, the agency treats it as immaterial. Both mechanisms sit in the same paragraph, in the same list, supporting the same claim: that sensitive health information about visitors to a telehealth site was allegedly shared with an advertising platform, in tension with published promises that the service was "100% online, private, and secure" and that conditions would be treated "privately" (paragraph 66).

That structure is the legal argument in miniature. Section 5 of the FTC Act asks whether a practice is deceptive or unfair, and deception is measured against what the company told consumers. A promise of privacy is not a promise about JavaScript. If the promise was that health information stays private and health information nonetheless reached an advertising platform, the transport layer describes how the promise was allegedly broken. It is not a defense to having broken it.

The same logic holds under HIPAA. A disclosure is a release of protected health information outside the entity, and the definition says nothing about protocol. Nobody has ever argued that faxing a chart is safer than emailing it because the fax machine is on-premises, yet we accepted the equivalent argument about conversion events. Our broader treatment of that lives in server-side tracking alone is not HIPAA compliance, and the general question of whether either Meta integration can be used safely is covered in is the Meta Pixel or the Conversions API HIPAA safe. This article is about what changed when a federal regulator put the argument in a filed pleading.

It Was Not a Drafting Accident

You could read paragraph 70 as sloppy, sweeping up the Conversions API because it happened to share a vendor with the pixel. Paragraph 77 makes that reading hard to sustain. It enumerates the other advertising technologies allegedly present on the company's platforms, from Microsoft's Bing pixels and Criteo through Pinterest, Podsights, Reddit, StackAdapt, The Trade Desk, and X. Two entries carry an explicit server-side label: a Google Ads S2S Pixel and TikTok s2s. Someone building that exhibit knew the difference between a client-side tag and a server-to-server integration, wrote the difference down, and included both categories.

Paragraph 76 adds a third architecture, alleging that customer lists were uploaded to Snap so users could be matched to Snapchat accounts. That is not a tag at all. It is an offline file transfer. Between them, the allegations cover browser tags, server-to-server APIs, and batch list uploads, and treat all three as routes by which the same allegedly sensitive information reached advertising platforms. The theory of the case is indifferent to transport by design.

Why the Industry Believed Server-Side Was the Answer

The belief was not irrational. It came from a correct diagnosis and an incorrect conclusion.

The diagnosis: the browser is where accidents happen. A client-side pixel reads the page it lives on. By default it captures the full URL, which on a healthcare site frequently contains a condition name, a drug name, a provider specialty, or an appointment type. Automatic event detection can pick up form field values. A marketing team can add a third-party script through a tag manager without any engineering review. Nearly every pixel leak we have seen in an audit traces back to something the browser volunteered rather than something an engineer chose to send.

The conclusion people drew: if the browser is the problem, take the browser out of the loop and send events from your server, where you decide the payload explicitly.

That last clause is where the reasoning quietly collapses. "Where you decide the payload explicitly" describes an opportunity, not a result. Server-side gives you the ability to control the payload. It does not exercise that ability on your behalf. A server container that receives a browser event and forwards it to Meta without inspecting it has moved the leak one hop downstream and added latency. The data arriving at the ad platform is identical.

How Curve Handles the Server-Side Layer

Curve is built on the premise this complaint just made expensive: the server is not a hiding place, it is a checkpoint. Events are collected first-party, then sanitized on Curve infrastructure before anything is transmitted, so protected health information does not reach Meta, Google, Microsoft, TikTok, or any other destination. Because redaction happens at the egress boundary rather than in the browser, it applies to every event on every page regardless of what a tag manager change did last week. Destinations are configured individually, since the safe payload for a Google Ads conversion upload is not the safe payload for a Meta Conversions API call, and treating them as one pipeline is how fields leak. Curve also offers a Business Associate Agreement, which matters because a control you cannot contract for is a control you cannot rely on. There is more on the technical shape of that setup in our server-side tracking technical audit.

The Uncomfortable Part: Server-Side Usually Sends More

Here is the detail that turns a theoretical risk into a practical one. Teams rarely adopt the Conversions API for privacy. They adopt it for match rate.

Browser tracking has been degraded for years by tracking prevention, cookie lifetime limits, and ad blockers. The Conversions API restores measurement by letting you send customer information parameters directly: hashed email, hashed phone, name, city, state, ZIP, date of birth, an external ID, and the client IP address. Meta matches on those to reattach the conversion to a user. That is the value proposition, and it works.

Now put that in a healthcare context. A pixel firing on a condition-specific page sends a URL and a cookie identifier. The same event sent through a poorly scoped Conversions API integration can carry a hashed email, a phone number, a name, a birth date, an IP address, and a conversion labeled with the product line the person purchased. The second payload is far more identifiable than the first. The migration meant to reduce exposure increased it.

Paragraph 74 is where this lands. The FTC alleges the company "was only able to create audiences with such specificity because it flouted the promises it made to its users about treating their medical conditions 'privately' or keeping their health information private." Specificity is the tell. Audience precision is downstream of identity resolution, and identity resolution is what the customer information parameters are for. The complaint reasons backward from marketing capability to data disclosure, a technique that works on your ad account too, because a regulator can read audience definitions and conversion action names without ever seeing your code.

The Three Questions That Replace "Is It Server-Side"

If transport is not the test, something has to be. A reviewer, whether a regulator, opposing counsel, or your own privacy officer, is asking three questions.

• What arrived? Not what you intended to send. What the destination received, field by field, in production, on a real user journey: event name, custom parameters, page URL, referrer, user data parameters, and any conversion or content identifier that encodes a clinical category.
• Is it identifiable? Hashing an email does not make it anonymous. It makes it a stable pseudonym the recipient can and will match against an account. If the platform can link the record to a person, the record is identifiable for this purpose.
• Did the consumer agree, measured against what you told them? A privacy policy paragraph does not neutralize a homepage claim of being "totally private" and "discreet." Paragraph 66 shows the FTC quoting marketing copy back at the defendant, including copy that ran on TV, radio, and podcasts. Your loudest promise sets the standard, not your quietest disclosure.

All three can be answered without knowing whether a request originated in Chrome or in a Node process. That is the whole argument.

What to Actually Check This Week

A useful server-side review is short and evidentiary. Claims are worthless. Payloads are not.

• Capture a real outbound Conversions API request from production and read every field. If nobody can produce one within a day, that is itself the finding.
• Inventory the customer information parameters you populate, and for each write down the measurement outcome it buys. Anything without an answer is pure liability.
• Check whether your server container forwards the browser payload verbatim. A pass-through is not a control.
• Read your event names and conversion action names as a stranger would. A conversion named after a condition or a medication is a disclosure in the label alone, before any parameter is considered.
• Confirm whether page URL and referrer ride along in server-side events. They usually do, by default, and they are the most common carrier of clinical context. Check offline and batch uploads separately.
• Verify a Business Associate Agreement exists with every vendor in the path, and see why a BAA alone is not enough.

For a structured version, our guide to identifying PHI leakage in ad tracking walks through it in order.

One more thing worth registering. GoodRx and BetterHelp both settled on consent in early 2023. This matter is being litigated, seeks civil penalties, and carries two state co-plaintiffs, which is escalation rather than repetition. The pixel lawsuit and settlement tracker has the wider pattern.

Frequently Asked Questions

Does this mean the Conversions API is not HIPAA compliant?

No integration is compliant or non-compliant on its own. Compliance is a property of the payload, the agreements in place, and the permissions obtained. The Conversions API can be configured to carry only a conversion signal and a non-clinical identifier, and it can be configured to carry a hashed email attached to a condition-specific event. The complaint suggests a regulator will look at which one you chose rather than at the API name.

Should we roll back our server-side setup and go back to the pixel?

No, that would make things worse. Client-side tracking gives you less control over the payload, and the browser volunteers URLs and form values you never chose to send. Keep the architecture and add what it was missing: enforced redaction at the point of egress, before any request reaches an ad platform.

If we hash email addresses before sending them, are we in the clear?

Hashing protects data from casual exposure. It does not de-identify, because the recipient hashes its own user list the same way and matches on the result. That is the entire mechanism by which advanced matching works. Treat a hashed identifier as an identifier.

Our vendor signed a BAA. Does that resolve the exposure?

A BAA governs the relationship with that vendor. It does not authorize disclosure to a downstream advertising platform that has not signed one, and it does not cure a deception claim built on public marketing promises. The FTC Act theory here runs on what consumers were told, a separate track from HIPAA entirely.

How would anyone find out what our server sends?

Through discovery, through the ad platform, through your own audience definitions and conversion action names, and through researchers who inspect traffic on public healthcare sites and publish what they find. Paragraph 74 shows an approach needing no code access at all: reason from the specificity of the audiences a company built back to the data required to build them.

This article reflects the public record as of July 2026. The allegations are unproven, the case is at its earliest stage, and Hims has denied them, stated that its privacy policy makes clear that users may choose how their data is used, and said it intends to defend itself.

If your team migrated to server-side tracking and called that the compliance answer, this complaint is the prompt to go read the payload. Curve makes that payload safe by construction: events sanitized server-side before egress, a BAA available, each destination configured separately. See how it works at curvecompliance.com.