Meta’s Health and Wellness restrictions limit what certain websites and apps can share through Meta Business Tools.

That applies to both the browser Pixel and server-side Conversions API.

Being placed in the category does not mean Meta caught a clinic sending medical records. Meta also categorizes websites and apps based on their subject matter, products and services. A GLP-1 clinic, compounding pharmacy, telehealth brand or wellness business may therefore receive health-related data restrictions.

PHI — protected health information — is a HIPAA term. Meta’s rules around sensitive health information are broader and can affect advertisers that are not HIPAA-covered entities.

The reverse is also true. Not every visit to a health website automatically contains PHI. HHS notes that a federal court vacated the part of its tracking guidance that treated an IP address plus a visit to a public healthcare webpage as automatically enough, on its own, to trigger HIPAA.

This is not legal advice. It is a practical reading of what Meta says it restricts, what the 2026 public record shows, and what you can check inside your own data source.

At Scoreify, we see this distinction regularly: a health advertiser can have perfectly legitimate Meta ads while still facing restrictions on what its website is allowed to send back to Meta. Ad approval and data-source restrictions are separate systems.

Meta can apply different levels of restriction depending on the source.

Core setup can remove custom parameters and strip the URL after the domain.

Certain standard events can be blocked, including events such as Purchase, Lead, InitiateCheckout or AddToCart. The exact events affected are shown in the notice for your own source.

Full restrictions can prevent event data from that source being shared or used for normal campaign optimisation in affected regions.

The important part: not every health business gets the same restriction.

Check the notice on the actual data source.

An approved ad also does not mean the tracking behind it is allowed. Creative review and data-source restrictions are separate systems.

In June 2026, Meta explained these controls in an amicus brief filed with the U.S. Supreme Court in Salazar v. Paramount.

Meta described category-based restrictions, URL truncation under Core Setup and human review of custom-event names in categories such as healthcare.

Separately, in July 2026, the FTC sued Hims & Hers. The complaint alleges the company shared health information with advertising platforms using tools including the Meta Pixel and Conversions API.

Those are allegations, not findings.

But the case makes an important point:

Moving the same data from the browser to a server does not automatically solve the privacy problem.

A field does not need to say “diagnosis” to reveal health information.

A normal Purchase event could become sensitive when it is combined with a URL, product name and person identifier.

That is the better test:

Changing a treatment name to a code does not necessarily solve the problem if the overall transmission still reveals the same health relationship.

For CAPI, fields such as email and phone are normally normalised and SHA-256 hashed before being sent to Meta.

That helps Meta match the data without receiving the original email or phone number in plain text.

It does not make the person anonymous.

And fields such as fbc, fbp, browser IP address and user-agent are sent unhashed rather than treated like email or phone.

Hashing an identifier by itself is also not the same thing as HIPAA de-identification.

Open the data source in Events Manager and review its category, restriction notice, diagnostics and event settings.

If Meta has categorised the source incorrectly, you can request a review.

The restriction notice is the important part because it tells you what Meta is applying to that specific source.

Do not only inspect your Pixel code.

Look at what your browser, server, plugins, forms, CRM, checkout and other integrations actually send.

Pay particular attention to URLs, event names, product names, form answers, custom parameters and free-text fields.

The goal is simple:

Health information that Meta should not receive should not be in the payload.

Server-side tracking can help because it gives you a place to allow or remove specific fields before they reach Meta.

RixelAI is built for this layer: inspecting what your Pixel and CAPI actually send, then filtering the outbound payload before it reaches Meta.

But installing CAPI or server-side tagging does not automatically make the data compliant.

If a browser Pixel is still sending the same information, the problem remains.

And if the event itself reveals a sensitive health relationship, deleting a couple of parameters may not be enough.

Renaming a restricted treatment purchase to something generic does not automatically make it acceptable.

Meta has said healthcare custom-event names may be human-reviewed.

The question is still what the event actually represents and what information Meta receives with it.

A 200 response from the API means Meta received the request.

Seeing the event inside Test Events means it arrived.

Neither proves Meta will allow you to optimise campaigns toward it.

Check the restriction status and event eligibility inside Events Manager.

Addressing Meta’s health and wellness restrictions may involve two different parts of your advertising setup.

If Shopify is sending health-related product names, URLs or searches to Meta, RixelAI rebuilds the event payload using only the data Meta needs for measurement.

If the problem is ad rejections, account restrictions or unstable delivery, Scoreify provides regulated health advertisers with stronger Meta account infrastructure and hands-on policy support.

These services address different parts of the problem: