Conversions API

The Conversions API (CAPI) is Meta's way of receiving events from your server instead of from a visitor's browser. Your backend, CRM, or a partner integration sends an HTTP POST request to Meta's Graph API at an address built from your Pixel ID, with an access token attached. Each event carries an event_name such as Purchase, an event_time as a Unix timestamp in seconds, an action_source such as website, and a user_data block that holds the identifiers Meta uses to match the event to a person. You manage the connection in Events Manager, where the same data set (the Pixel ID) receives both browser and server events. The access token you attach is a credential, so store it on the server and never in page code. Most small shops use a partner integration instead of hand-written code.

Matching depends on the customer information you send. Meta requires fields like email (em), phone (ph), first and last name, city, state, zip, and country to be normalized and hashed with SHA-256 before sending. Email is trimmed and lowercased. Phone numbers drop symbols, letters, and leading zeros and include the country code. Some values must not be hashed: client_ip_address, client_user_agent, fbp, and fbc. The fbp value is the browser ID the Pixel stores in the _fbp cookie, and fbc carries the fbclid from an ad click. Server events are only as good as what your backend knows at the moment of sending. A checkout that saves the email, phone, and browser IDs with the order gives you more to match than one that records only an order number and a total.

CAPI works alongside the Pixel, not against it. The recommended setup sends the same event from both sources and gives them a shared event_id. Meta deduplicates when the Pixel eventID equals the server event_id and the event names match, both sent to the same Pixel ID, and only if the second copy arrives within 48 hours of the first. If you have no event_id, Meta falls back to matching on event_name plus fbp or external_id, which generally works only when the browser event arrives first. Events sent from one source alone are not deduplicated against themselves. Keep the two sources aligned in more than the ID. Send the same event names, the same currency, and the same value from the Pixel and the server, or one copy will disagree with the other and you will chase a gap that is really a formatting difference.

The usual mistakes are all about matching and timing. Sending server events without an event_id means purchases get counted twice, which inflates reported results and trains delivery on bad numbers. Sending too little customer information leaves events unmatched, so they cannot be attributed to an ad. Hashing the fields Meta says not to hash breaks matching. Late uploads fail too: event_time can be up to 7 days before the send, and if any event in a request is older, the whole request returns an error and nothing is processed. For offline store events with physical_store as the action source, Meta says to upload transactions within 62 days of the conversion. There is also a quieter mistake: sending every event twice from the server alone, for example when a webhook retries. Because deduplication needs a matching event_id, a stable ID built from the order number is safer than a random one generated on each send.

To read it in reporting, open Events Manager and look at each event's source: Browser, Server, or both. Check the event match quality information and the deduplication status for Purchase and Lead. This week, pick your one most valuable event, confirm the browser and server copies share an event_id, and compare the server count to your store or CRM orders for the same dates. If the server count tracks your real orders more closely than the Pixel does, that gap is the signal you were losing before. When you review it, test one real order end to end instead of trusting a green status light. Place the order, find it in the event list, check its source, and confirm only one Purchase was kept.