Meta Conversions API Setup Guide: CAPI, Deduplication and EMQ Done Right

The Meta Conversions API (CAPI) is a server-to-server interface that sends conversion events directly from your backend to Meta, instead of relying only on the browser-based Meta Pixel. Where the Pixel fires from the user’s device and is blocked by ad blockers, Safari Intelligent Tracking Prevention (ITP) and consent rejection, CAPI sends the same events from your server, where those restrictions do not apply. The result is more complete conversion data, which Meta’s algorithm uses to optimise ad delivery and attribution.

This guide explains how CAPI and the Pixel work together, why deduplication via a shared event_id is the single most important detail to get right, how to raise Event Match Quality (EMQ), the trade-offs between server-side GTM and a direct API integration, what to watch on Shopify now that script tags are gone and the GDPR considerations that apply in the EU. It is vendor-neutral and current as of September 2026: every central claim links to the official Meta or Shopify documentation.

What the Meta Conversions API actually is

The Pixel is a JavaScript snippet that runs in the visitor’s browser. When someone views a product or completes a purchase, the Pixel sends an event (ViewContent, Purchase and so on) to Meta from the client. This is fragile by design: the browser is a hostile environment for tracking.

CAPI moves that same event to the server. Your backend, a server-side tag container or a gateway sends a structured HTTP request to Meta’s Graph API endpoint with the event name, a timestamp, hashed customer data and event parameters. Because the request originates from your infrastructure, it is not affected by browser extensions, cookie limits or script blocking. Meta states that it processes server events the same way as Pixel events, see the Conversions API overview.

CAPI is not a replacement for the Pixel. The two are designed to run in parallel. The Pixel still captures the rich, real-time browser context (the _fbp and _fbc cookies, the user agent, the click ID from the ad). The server event adds reliability and can carry first-party identifiers the browser does not expose cleanly. Meta then stitches the two streams together.

CAPI vs Pixel: why you need both in parallel

A common mistake is treating CAPI as an either/or decision. It is not. The architecture Meta recommends is called a redundant event setup: Pixel plus CAPI for every important event, with deduplication so a single purchase is only counted once.

Each layer covers the other’s blind spots:

Layer	Strength	Weakness
Meta Pixel (browser)	Rich browser signals (fbp, fbc, click ID), real-time	Blocked by ad blockers, ITP, consent rejection, network failures
Conversions API (server)	Survives blockers and ITP, can send hashed first-party data	No native browser context unless you forward it, depends on your data quality

How much a deduplicated CAPI recovers depends on traffic mix, consent rates and how clean the implementation is. Two official figures set the scale: in its April 2026 announcement Meta reports an average 17.8 percent lower cost per result for advertisers using CAPI alongside the Pixel. In its best practices Meta also recommends an event coverage of 75 percent as the target ratio of CAPI events to Pixel events. Treat both as orientation, not as a guarantee for your shop.

For the underlying signal-loss problem this solves, our server-side tracking service covers the full browser-to-server architecture, not just Meta.

What changed in 2026

If you compare this guide against a setup from 2024 or 2025, four changes matter:

• Graph API version. The current version is v26.0 (released 29 July 2026). v20.0 was sunset on 24 September 2026, v21.0 keeps working until 21 January 2027. Check the version in your endpoint against the Graph API changelog and schedule updates before a version expires.
• Meta-enabled Conversions API. Since 15 April 2026 Meta offers a web-only CAPI variant that is switched on with one click in Events Manager, is free and mirrors the Pixel’s events and parameters server-side with automatic deduplication. According to Meta, existing Pixel users get 30 days’ notice before automatic enablement and can adjust or disable it in Events Manager. Source: announcement and comparison of setup options.
• AI-enhanced Meta Pixel. From the same announcement: the Pixel automatically captures additional business context such as product names, availability and business details, without developers maintaining those parameters by hand.
• Click attribution. Since the announcement of 3 March 2026, only link clicks count as click-through attribution for website and in-store conversions. Other interactions such as shares, saves or likes move to the new engage-through attribution. This is a reporting change, not a billing change. If your conversion numbers dropped in spring 2026, check this effect first before suspecting your CAPI setup.

The Meta-enabled variant is a good start for small shops without developers. It only sends what the Pixel already sees, though. More identifiers, server triggers such as order webhooks and your own consent logic still need one of the integrations below.

Required parameters, time windows and the access token

Before quality matters, the request has to be accepted at all. Meta documents the rules in the server event parameters and in Using the API:

• Required fields per event: event_name, event_time, user_data and action_source. Website events additionally need event_source_url and, inside user_data, the client_user_agent. action_source must be accurate, so website for shop purchases.
• event_time is a Unix timestamp in seconds and may be at most 7 days in the past, otherwise Meta rejects the whole request. Meta recommends sending events as soon as they occur, ideally within an hour.
• Batching: Up to 1,000 events per request in the data array. The Conversions API has no rate limit of its own, calls count against the Marketing API limit.
• Access token: Generate it in Events Manager under Settings in the Conversions API section via “Generate access token” or through a system user in Business Settings, see Get started. The token belongs on the server only, never in browser code or repositories. Since v12.0 these tokens are no longer tied to the Graph API version that was current when they were generated.
• test_event_code is an optional top-level field next to data, more on that in the testing section.

Event Match Quality (EMQ): the lever for lower cost per conversion

Event Match Quality (EMQ) is Meta’s score on a scale of 0 to 10 for how well the customer information sent with a server event lets Meta match that event to a Meta account. According to Meta’s help page, the score is calculated from the quality of the customer parameters you send and the share of event instances that could actually be matched to an account. Three details that are often missed:

• The score only exists for website events sent through the Conversions API with action_source website. Pixel-only events have no EMQ.
• The calculation uses data from the last 48 hours. If you send events only sporadically, the score is unreliable.
• Meta publishes no official thresholds for “good” or “bad”. Concrete recommendations on which parameters are missing appear in Events Manager next to each event.

This is not a vanity metric. Matched events are the basis for Meta attributing conversions and delivering ads to people more likely to convert. The higher the match quality, the more signal the optimisation receives.

How to raise EMQ

Send more identifiers, correctly normalised and hashed. Meta ranks the parameters in user_data by priority (source: the same help page):

Priority	Parameters
High	Email (em), click ID (fbc)
Medium	Phone number (ph), country (country), date of birth (db), external ID (external_id), browser ID (fbp), Facebook login ID (fb_login_id)
Low	First name (fn), last name (ln), city (ct), ZIP (zp), lead ID (lead_id)

The normalisation and hashing rules are in the customer information parameters. The most important ones:

• Hash with SHA-256: em, ph, fn, ln, ct, st, zp, country, db and ge. For external_id Meta recommends hashing.
• Never hash: fbc, fbp, client_ip_address and client_user_agent.
• Email: trim leading and trailing spaces, convert everything to lowercase.
• Phone: remove symbols, letters and leading zeros, digits only. The country code must be included, even if you only serve one country.
• Names: lowercase with no punctuation. City: lowercase with no punctuation, no special characters and no spaces. ZIP: lowercase with no spaces and no dash. Country: ISO 3166-1 alpha-2 in lowercase, for example de.
• fbc has the format fb.1.{timestamp in milliseconds}.{fbclid}. If the cookie is missing because the Pixel was blocked, you can build the value server-side from the fbclid URL parameter in exactly this format.
• Meta recommends sending client_ip_address and client_user_agent with every event and notes that fbp and fbc can change and should be refreshed regularly (see best practices for developers).

import crypto from "crypto";

function hash(value) {
  if (!value) return undefined;
  const normalized = String(value).trim().toLowerCase();
  return crypto.createHash("sha256").update(normalized).digest("hex");
}

const userData = {
  em: hash(customer.email),
  ph: hash(customer.phone?.replace(/\D/g, "").replace(/^0+/, "")),
  fn: hash(customer.firstName),
  ln: hash(customer.lastName),
  ct: hash(customer.city?.replace(/[^\p{L}]/gu, "")),
  zp: hash(customer.zip?.replace(/[\s-]/g, "")),
  country: hash(customer.countryCode),
  external_id: hash(String(customer.id)),
  fbc: cookies._fbc,
  fbp: cookies._fbp,
  client_ip_address: request.ip,
  client_user_agent: request.headers["user-agent"],
};

The hash function handles trimming and lowercasing. The phone number is reduced to digits and stripped of leading zeros beforehand, so it must already include the country code. For city and ZIP the regular expression removes spaces and dashes, as Meta requires. fbc, fbp, IP and user agent go in unchanged.

The single biggest EMQ win for most shops is forwarding the _fbc (click ID) and _fbp (browser ID) cookies from the Pixel to the server event, plus a hashed email. Capture fbp and fbc client-side and pass them into your server payload.

Deduplication: the detail that breaks setups when wrong

When you run the Pixel and CAPI together, the same purchase is reported twice: once from the browser, once from the server. Without deduplication, Meta counts it twice, inflating conversions and corrupting optimisation. Deduplication is mandatory, not optional.

The rules are in Meta’s deduplication documentation: Meta deduplicates two events when they share the same event_name and the same event_id and the second event arrives within 48 hours of the first event with that event_id. If the contents do not differ meaningfully, Meta generally keeps the event received first, regardless of whether it came from the browser or the server. The customer data from both is merged.

As an alternative, Meta also deduplicates on event_name plus fbp or external_id. This variant has a catch: a server event is only discarded if a matching browser event arrived in the 48 hours before it. Rely on the event_id instead.

The rule is therefore simple and unforgiving: the Pixel event and the CAPI event for the same action must carry the same event_id.

Generate the event_id once, then use it for both. A reliable pattern is to derive it from a stable transaction identifier (the order ID) so the browser and server independently compute the same value. In the browser the parameter is called eventID with a capital ID, on the server event_id.

const eventId = "purchase_" + orderId;

fbq("track", "Purchase", {
  value: 49.90,
  currency: "EUR",
  content_ids: ["SKU-123"],
}, { eventID: eventId });

await fetch(
  `https://graph.facebook.com/v26.0/${PIXEL_ID}/events?access_token=${ACCESS_TOKEN}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      data: [{
        event_name: "Purchase",
        event_time: Math.floor(Date.now() / 1000),
        event_id: "purchase_" + orderId,
        action_source: "website",
        event_source_url: orderUrl,
        user_data: userData,
        custom_data: {
          value: 49.90,
          currency: "EUR",
          content_ids: ["SKU-123"],
          order_id: String(orderId),
        },
      }],
    }),
  }
);

value and currency are required for Purchase, currency as a three-letter ISO 4217 code, see custom data parameters. order_id is optional but helps with troubleshooting.

Three things people get wrong here:

1. Mismatched event_name. Purchase on the Pixel and purchase on the server will not deduplicate. Casing and spelling must be identical.
2. A random event_id generated separately on each side. They will never match. Always derive it from a shared, deterministic source.
3. Sending the server event too late. 48 hours sounds generous, but event_time may be at most 7 days old and Meta optimises better with fresh events. Send it promptly, ideally near-real-time on the order confirmation or via an order webhook.

Implementation paths compared: direct API vs server-side GTM vs gateway

There is no single correct way to send CAPI events. The right choice depends on your stack, your team and how much control you want over the data. The five common paths:

Path	What it is	Best for	Trade-off
Direct API	Your backend calls Meta’s Graph API itself	Teams with backend access and developers	Full control, full maintenance burden
Server-Side GTM (sGTM)	A server container receives events and forwards them to Meta via Meta’s tag	Marketing teams wanting one server hub for all platforms	Needs a hosted container; some complexity
Conversions API Gateway	A Meta-provided instance in your own AWS or GCP account	Pixel users without developers and without a shop platform	Cloud costs, less control over identifiers
Meta-enabled CAPI	One click in Events Manager, Meta mirrors the Pixel events server-side	Small shops, quick start	Web only, only what the Pixel sees
Native platform integration	The built-in CAPI connector of Shopify or WooCommerce	Quick start, simple stores	Limited deduplication and EMQ control

Server-side GTM is the most common choice for shops that already use GTM, because one server container can feed Meta, GA4, TikTok and others from a single, consented data stream. Meta provides the “Conversions API Tag” by facebookincubator in the template gallery for this; the guide recommends triggering the Pixel tag and the server tag from the same GA4 event so both carry the same event_id. Our server-side GTM work sits in this layer.

Direct API gives the cleanest control and no third party in the data path, which matters for GDPR and for data minimisation. It costs developer time and ongoing maintenance. Meta estimates 2 to 4 weeks for a new direct integration in its comparison.

Conversions API Gateway is, according to Meta’s help page, a no-code self-service option: you provision an instance in your own AWS or GCP account, setup takes under 30 minutes, the event_id is generated and propagated automatically and cloud fees start at 30 US dollars per month. Meta recommends it for advertisers who already use the Pixel, do not yet send web events via CAPI, spend at least 300 US dollars per month on web-optimised campaigns and do not run on a shop platform such as Shopify or WooCommerce. Technical details are in the Gateway documentation.

Gateways and native integrations are the fastest to switch on but the hardest to get to high EMQ and reliable deduplication, because you have less control over which identifiers are sent and how event_id is generated. They are a reasonable starting point, not usually the end state for a serious advertiser.

Shopify specifics

Shopify has a native Meta integration through the “Facebook & Instagram” app, available from the Basic plan upwards. In the data sharing settings the “Standard” level sends only through the Pixel, while “Enhanced” and “Maximum” additionally send the purchase event through the Conversions API and, according to Shopify’s help, share the customer’s name, location, email and phone number. Meta recommends “Enhanced” or “Maximum” in its connection guide. It is a fine baseline, but it is limited: you have little control over which identifiers are sent and deduplication with any custom Pixel you also run can be inconsistent.

Three deadlines rebuilt Shopify tracking in 2025 and 2026:

• Checkout and thank-you page: checkout.liquid, the “Additional Scripts” field and script tags on the thank-you and order status pages ended for Plus stores on 28 August 2025 and for all other stores on 26 August 2026. Source: Shopify help on the checkout upgrade and ScriptTag deprecation. Tracking on these pages now runs exclusively through web pixels (app pixels or custom pixels).
• Storefront script tags: From 1 October 2026 apps can no longer create or modify script tags. From 1 March 2027 Shopify stops injecting them altogether. Source: Shopify changelog.
• Protected customer data: Since 10 December 2025 Shopify returns only null for email, name, phone and address in checkout_completed to app pixels without approved protected customer data scopes. Custom pixels you create yourself in the admin are not affected. Source: Shopify changelog. The same logic applies to webhooks: without approval, protected fields are redacted from order payloads, see protected customer data. So check whether your pixel app and your webhook app receive the fields at all before blaming Meta for a low EMQ.

For a high-quality Shopify setup:

• Use a custom pixel or an app pixel with approved scopes for the browser event checkout_completed. The event fires once per checkout, typically on the thank-you page. It provides checkout.order.id as a stable source for the event_id, see the checkout_completed reference.
• For the server event, the orders/paid webhook is the most reliable trigger. It fires as soon as an order is paid, carries the full order and is not affected by the customer closing the tab on the thank-you page.
• Derive event_id from the Shopify order ID on both the pixel and the webhook handler so they deduplicate.
• Capture _fbp and _fbc in the storefront and persist them with the order (a cart attribute or note attribute works) so the webhook handler can include them in user_data. The order itself provides IP address and user agent via browser_ip and client_details.user_agent.

export async function handleOrderPaid(order) {
  const attribute = (name) =>
    order.note_attributes?.find((a) => a.name === name)?.value;

  await sendCapiEvent({
    event_name: "Purchase",
    event_time: Math.floor(new Date(order.processed_at).getTime() / 1000),
    event_id: "purchase_" + order.id,
    action_source: "website",
    event_source_url: order.order_status_url,
    user_data: {
      em: hash(order.email),
      ph: hash(order.phone?.replace(/\D/g, "").replace(/^0+/, "")),
      fn: hash(order.billing_address?.first_name),
      ln: hash(order.billing_address?.last_name),
      ct: hash(order.billing_address?.city?.replace(/[^\p{L}]/gu, "")),
      zp: hash(order.billing_address?.zip?.replace(/[\s-]/g, "")),
      country: hash(order.billing_address?.country_code),
      external_id: hash(String(order.customer?.id ?? order.id)),
      fbp: attribute("fbp"),
      fbc: attribute("fbc"),
      client_ip_address: order.browser_ip,
      client_user_agent: order.client_details?.user_agent,
    },
    custom_data: {
      value: Number(order.total_price),
      currency: order.currency,
      content_ids: order.line_items.map((i) => String(i.product_id)),
      order_id: String(order.id),
    },
  });
}

The handler reads fbp and fbc from the note attributes the custom pixel attached at checkout. event_time uses the order’s payment timestamp so that webhooks processed with a delay still stay inside the 7-day window. event_source_url and client_user_agent are required for website events and come entirely from the order here.

WooCommerce follows the same logic. The Facebook for WooCommerce plugin ships CAPI without additional configuration according to its vendor and deduplicates via a shared event ID. Other platforms: fire the server event from an order-completed hook, share the event_id with the Pixel and forward as many hashed identifiers as you legally can.

Testing in Events Manager

Do not assume it works. Validate it. Meta’s Events Manager gives you the tools:

1. Test Events tab. Open Events Manager, pick your dataset under Data Sources, open the Test Events tab and copy the test ID from the server events section. Add it as test_event_code at the top level of your payload and trigger a real action. According to Meta’s guide, events appear in the feed shortly after sending and stay visible there for 24 hours. The Payload Helper checks the structure before you send.
2. Confirm deduplication. The Test Events tool shows which events were received, deduplicated or dropped, see Meta’s help page on deduplication. If you see two separately counted events, your event_id or event_name do not match.
3. Check the Event Match Quality score. In the dataset overview, each server event lists its EMQ, calculated from the last 48 hours. Use the recommendations next to it to see which identifiers are missing and iterate.
4. Watch the Diagnostics tab. Meta flags missing parameters, hashing problems and dropped events here, split into critical issues and warnings. An issue counts as active for 24 hours and moves to “Previously detected” after three days without action, where the resolution steps disappear, see Diagnostics in Events Manager. Fix issues while they are active.

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1790000000,
    "event_id": "purchase_1029",
    "action_source": "website",
    "event_source_url": "https://shop.example/checkout/thank-you",
    "user_data": {
      "em": "<sha256>",
      "client_ip_address": "203.0.113.10",
      "client_user_agent": "Mozilla/5.0",
      "fbp": "fb.1...",
      "fbc": "fb.1..."
    },
    "custom_data": { "value": 49.90, "currency": "EUR" }
  }],
  "test_event_code": "TEST12345"
}

Remove the test_event_code before going to production. Important, because it is often claimed otherwise: events with a test_event_code are, according to Meta, not dropped but flow into Events Manager and are used for targeting and measurement. So test with real test purchases you would clean up anyway, not with made-up data.

GDPR considerations for the EU

CAPI does not exempt you from data protection law. Sending personal data to Meta from your server is still processing of personal data and in the EU it requires a lawful basis and, in almost all cases, consent. This is a technical explanation, not legal advice; confirm your specific setup with your data protection officer or counsel.

Key points for a GDPR-compliant setup:

• Consent is still required. Server-side does not mean consent-free. Meta’s Business Tools Terms explicitly list the Conversions API among the Business Tools and oblige you, where the law requires it, to obtain verifiable consent before you transmit data. If the user rejects marketing cookies, you do not send their identifying data to Meta. Couple CAPI to your consent management platform.
• Consent in the browser and on the server. For the Pixel, Meta provides the consent API: fbq('consent', 'revoke') before init pauses the Pixel, fbq('consent', 'grant') releases it after consent. This control only works in the browser. For CAPI you have to store the consent state with the event yourself (on Shopify, for example, as a cart attribute) and gate the server call on it. Google Consent Mode governs Google tags, not Meta.
• Hash personal data. Email, phone and name are sent SHA-256 hashed. Hashing reduces exposure but the data is still personal data under the GDPR, so it does not remove the consent requirement.
• Data minimisation. Send only the identifiers you actually need for matching. Do not forward fields with no tracking purpose.
• Joint controllership instead of a processing agreement. For the collection and transmission of the event data you are a joint controller with Meta Ireland under Article 26 GDPR. Meta’s Controller Addendum governs this: you are responsible for the lawful basis of your processing and for informing data subjects, including the notice that Meta Ireland is a joint controller and where its privacy policy is. There is no classic data processing agreement for this data.
• Document it. Record the lawful basis, the consent flow and the data flow in your processing records and name the Conversions API in your privacy policy.

The advantage of a clean, server-side architecture is precisely that it gives you a single, auditable point where consent is enforced and identifiers are controlled, instead of tracking scattered across browser scripts. For the consent and lawful-basis layer specifically, see our tracking and consent work.

Recovering lost signal: what to expect

A deduplicated, high-EMQ CAPI is the most effective way to shrink the conversion blindness that iOS App Tracking Transparency, ITP and ad blockers created. The most reliable official figure comes from Meta’s April 2026 announcement: advertisers using CAPI alongside the Pixel saw an average 17.8 percent lower cost per result than advertisers without CAPI. Some baseline underreporting is expected to remain; CAPI shrinks the gap rather than closing it entirely.

Set realistic expectations: you are recovering signal and improving optimisation, not buying perfect tracking. The combination of more complete data, an event coverage close to the 75 percent Meta recommends and higher match quality is what moves cost per action.

Implementation checklist

• Pixel and CAPI both fire for Purchase (and other key events)
• A shared, deterministic event_id on both sides (derived from order ID)
• Identical event_name casing on Pixel and server
• Endpoint on a current Graph API version (September 2026: v26.0), sunset dates from the changelog noted
• action_source, event_source_url and client_user_agent set on every website event
• Server event sent promptly (webhook or near-real-time), event_time never older than 7 days
• fbp and fbc cookies forwarded to the server event
• At least email plus several other hashed identifiers in user_data
• All personal data SHA-256 hashed and normalised according to Meta’s rules
• Access token stored server-side only
• Consent gating in the browser (consent API) and on the server wired to your CMP
• Validated in Events Manager Test Events, deduplication confirmed, test_event_code removed again
• EMQ checked and iterated with the recommendations in Events Manager
• Event coverage heading toward 75 percent
• Diagnostics tab without active issues
• Shopify: web pixel instead of script tags, protected customer data approvals checked
• Privacy policy names the joint controllership with Meta Ireland

Frequently asked questions

What is the Meta Conversions API and how does it differ from the Pixel?

The Pixel sends conversion events from the visitor’s browser; CAPI sends the same events from your server. CAPI survives ad blockers, Safari ITP and consent-driven script blocking that stop the browser Pixel. They are designed to run together, not as alternatives.

Do I still need the Meta Pixel if I set up CAPI?

Yes. The Pixel captures real-time browser context (the _fbp and _fbc cookies, click IDs) that improves matching. The recommended setup is Pixel plus CAPI for every important event, deduplicated by a shared event_id.

Is the Meta Conversions API GDPR-compliant?

CAPI can be operated in a GDPR-compliant way, but it is not automatically compliant. Sending personal data to Meta still requires a lawful basis (in practice, consent), informing data subjects about the joint controllership with Meta Ireland and a transparent privacy policy. This is a technical explanation, not legal advice.

What is Event Match Quality and what is a good score?

EMQ is Meta’s 0 to 10 score for how well the customer information sent with a server event lets Meta match it to a Meta account, calculated from the last 48 hours of data. Meta publishes no fixed thresholds but shows per event in Events Manager which parameters are missing. You raise the score by sending more accurate, correctly hashed customer identifiers per event, above all email and click ID.

How does deduplication between Pixel and CAPI work?

Meta deduplicates events that share the same event_name and event_id and arrive within 48 hours of the first event with that ID. With identical content, Meta generally keeps the event received first. Both the Pixel and the server event for the same action must send an identical event_id and an identical event_name.

What is the difference between server-side GTM, a CAPI gateway and a direct API integration?

Direct API means your backend calls Meta’s Graph API itself (most control, most maintenance). Server-side GTM routes events through a server container that can feed multiple platforms. The Conversions API Gateway is a Meta-provided instance in your own cloud account (fastest setup, least control). All three can work; control over identifiers and event_id is the differentiator.

How do I set up the Conversions API for Shopify?

Use a web pixel for the browser event checkout_completed, trigger the server Purchase event from the orders/paid webhook, derive event_id from the Shopify order ID on both sides and forward fbp/fbc plus hashed customer data. Since 26 August 2026 no script tags run on the thank-you page even in non-Plus stores. Since 10 December 2025 app pixels need approved scopes to see customer data.

How long does it take to set up the Meta Conversions API?

A focused implementation for the core events takes a few hours of work; reaching high EMQ and validating deduplication across all events and edge cases typically takes longer with iteration. Meta itself estimates 2 to 4 weeks for a new direct integration and one click for the Meta-enabled variant.

---

Getting CAPI right is mostly about the unglamorous details: a deterministic event_id, identical event names, the right hashed identifiers, a current API version and consent enforced in one place. If you would rather have it implemented and validated for you, see our Meta Conversions API service or the broader server-side tracking service. The best place to start is a free initial consultation: in a free strategy call we map what your current setup is missing and agree the fastest path to a clean, deduplicated CAPI.