Meta Conversions API for UK dental practices, and the health-data limits

Why the pixel is not enough

The Meta Pixel is a snippet of code on your website that reports visits and actions to Meta from the visitor's browser. The browser is an unreliable messenger. Ad blockers stop it, browsers limit tracking, visitors decline cookies, and pages close before the code fires.

The Conversions API is Meta's server-side route. Meta describes it as a connection between an advertiser's marketing data on its server and Meta's systems, with server events linked to a dataset and processed like Pixel events.⁵ Because your server sends the event, it isn't at the mercy of the browser. Meta recommends running both together, which it calls a redundant setup.¹

For most businesses the story ends there: add CAPI, send purchases, and Meta learns which clicks became customers. For a dental practice, the "send purchases" step is exactly where the trouble starts.

What Meta allows health advertisers to send

Three Meta documents set the limits. None of them has a dental carve-out.

The Business Tools Terms. These are the terms you accept when you use the Pixel or CAPI. Section 1.h(iv) says you will not share data that "includes or is based on, directly or otherwise, health information". The version I read is dated 3 November 2025.²

Prohibited information. Meta's help page lists what counts. It includes health information and gives examples including "Medical procedures, treatments and testing" and "places of treatment and counselling". Event names, conversion names and audience names must not "reflect, imply or be based on" any of it.³

Category restrictions. Meta classifies data sources, and its health and wellness category covers businesses associated with medical conditions, health statuses or provider and patient relationships.⁶ Once classified, restrictions come in tiers: core setup (custom parameters and URL paths after the domain are stripped), restriction of mid and lower-funnel standard events, and full restriction, where Business Tools can't be used for ads. They can apply to certain countries or globally, and you can't modify a Meta-assigned category, only ask for a review.⁴

Meta has also flagged custom conversions that suggest health conditions since 2 September 2025. A flagged custom conversion can't be used in new campaigns.⁷

Read together, here is where a dental practice stands. Meta doesn't say whether a generic consultation event from a dental practice counts as health information, so the two consultation rows are my reading of its terms, not Meta's stated position.

Offline events are the same question

Meta used to run a separate Offline Conversions API for in-person sales. It was discontinued in May 2025.⁸ Offline events now go through CAPI with the action source set to physical_store.⁹ For a practice, an attended consultation is an in-person event of this kind. Meta's prohibited list includes places of treatment,³ which is why I send attendance with no treatment, location detail or value, never send payments, and expect that Meta's category restrictions may still block it.

The timing rules are worth knowing even so. CAPI accepts an event_time up to seven days before you send it, and Meta's offline-events page says it returns an error for the whole request if any event is older than that. The same page says physical-store transactions should be uploaded within 62 days of the conversion.⁹ Those two statements sit side by side in Meta's documentation. Either way, a full-arch case that completes three months after the click can't be sent at all.

Limited Data Use is not a UK tool

Meta's Limited Data Use setting is sometimes suggested as a fix. Meta describes it as support for compliance with US state privacy laws, and lists US states only.¹⁰ It does not change what the Business Tools Terms let you share in the first place.

My position

For a dental practice, my position is:

1. Send Meta two stage events only: a booked consultation and an attended consultation. Never treatment names, clinical notes, conditions, prices or invoice values tied to a treatment.
2. Send them through the Conversions API, matched on email and phone hashed as Meta requires,¹¹ and only for patients whose explicit consent is recorded. The names are generic: Meta's standard Schedule event, which Meta defines as booking an appointment to visit one of your locations,¹² for the booking, and a plain custom event for attendance that names no treatment.
3. Check the dataset's category in Events Manager before relying on either event. If Meta restricts mid and lower-funnel events for the practice, those events may not be usable, and Meta says custom events on a restricted dataset are blocked until you review and confirm them.⁴ I don't rename or disguise events to get round a restriction. Meta then runs on upper-funnel events, and I measure Meta's patients inside the practice: the campaign tag on the link (a UTM parameter) and Meta's click identifier are captured with the enquiry, with consent, and joined to the patient record internally.
4. Run lead campaigns with no treatment questions on the form. How Meta ads should be run for a practice is covered in running Meta ads for a practice. What ad copy and targeting may say is a separate rulebook, on the Meta health ad policy page.

This is narrower than most CAPI guides. It's my reading of Meta's terms, not Meta's stated position, and a restriction Meta applies to the practice's dataset overrides it.

Setting up CAPI

If CAPI is only carrying events that pass both tests, the setup is simple. There are three common routes.

Whichever route, these rules apply.

• Send domain-level URLs only. The event source URL should not reveal a treatment page. Strip paths and query strings before sending.
• Hash customer information. If you send an email or phone number, Meta requires it hashed with SHA-256, a one-way scrambling method, before sending. The browser identifiers fbp and fbc, the IP address and the user agent are sent unhashed, as Meta specifies.¹¹
• Pick the right action source. Website events use website.¹³ An attended consultation is an offline event and uses physical_store.⁹
• Use generic, truthful event names. Standard events such as PageView are fine where the page itself reveals nothing.
• Send only the two consultation stages from the practice management system (PMS), and only with recorded consent. No treatment, clinical or invoice data: not as an event, not as a parameter, not as a value.

Deduplication

When the Pixel and CAPI both report the same action, Meta has to count it once. It does that by matching two fields: the Pixel's eventID must match the server's event_id, and the Pixel's event name must match the server's event_name. Meta only deduplicates events received within 48 hours of the first one.¹

There's a fallback that uses the fbp browser identifier or an external_id instead, but Meta says it only works when the browser event arrives first.¹ Rely on the event ID.

The practical rule: generate one event ID in the browser at the moment of the action and pass it to your server, so both copies carry the same value. If you skip this, Meta counts everything twice and your reported results double.

Consent

Two separate sets of rules apply, and neither replaces the other.

Cookies and pixels (PECR). The Privacy and Electronic Communications Regulations cover storing and reading information on a visitor's device. The ICO's guidance says that using these technologies for online advertising "requires consent".¹⁴ The ICO published its final guidance on storage and access technologies on 29 April 2026, and says separate work on online advertising under regulation 6 of PECR will follow.¹⁵ Check for updates before relying on the current position.

In practice, the Pixel must not fire until the visitor agrees. Meta provides a consent call for this: fbq('consent', 'revoke') pauses Pixel fires, and fbq('consent', 'grant') resumes them once consent is given. Meta says revoke must be called on every page.¹⁶ Server events should follow the same consent decision. The fbp and fbc values CAPI uses come from cookies, so without consent they should not exist. How the banner and tags fit together is on cookie consent on dental websites.

Patient data (UK GDPR). Health data is special category data. The ICO gives appointment details, reminders and invoices as examples of data that can reveal something about a person's health, and says a series of appointments at a specialist clinic can let you infer health data.¹⁷ A dental practice's records are that kind of data. Sharing them with an advertising platform would need a lawful basis, an Article 9 condition and patient-facing wording, and it would still have to pass Meta's own terms. The condition I rely on is explicit consent, UK GDPR Article 9(2)(a),¹⁸ asked for and recorded separately from the patient's consent to treatment. That is why the two stage events go only for patients whose explicit consent is recorded, and carry no treatment or clinical detail.

So consent is necessary but not sufficient. A patient can consent to measurement, and Meta's terms can still forbid you from sending the data.

If you run Meta ads and want to know which of them produce patients without sending Meta anything it should not have, email me at Fayez@imfayez.com. You can also read how I work first.