META ADS TRACKING GUIDE

Meta Conversions API (CAPI): How Server Events Actually Work

Conversions API allows marketing events to be sent to Meta from a server, ecommerce platform, CRM or another server-controlled source instead of relying only on browser JavaScript. But a strong CAPI implementation is not simply about getting events into Meta. Event naming, timing, matching information, event IDs, deduplication and data freshness all need to work together.

Last updated: 19 September 2026

CUSTOMER ↓ WEBSITE

BROWSER PATH

META PIXEL→BROWSER PURCHASE EVENT

SERVER PATH

STORE / BACKEND→CAPI PURCHASE EVENT

META DATASET / EVENTS MANAGER

MATCHINGDEDUPLICATIONOPTIMISATION SIGNAL

event: Purchase
source: browser
eventID: ORDER-DEMO-001
value: 799 DKK

Simplified illustrative architecture. No data is sent.

01 — FOUNDATION

What is Meta Conversions API?

CAPI gives businesses a direct connection between their marketing data and Meta. Events can originate in an ecommerce backend, server, CRM, partner integration, server-side tagging infrastructure or supported commerce platform.

Event origin is the system where the real action becomes known. Event transport is the route from that system to Meta. A Purchase may originate when the backend confirms an order and then be transported through CAPI. CAPI does not automatically replace Pixel; for web measurement the connections can be redundant and complementary.

ORIGIN

The order is confirmed in the store backend.

TRANSPORT

An integration or server layer builds the request.

DESTINATION

Meta dataset / Events Manager

Meta: Conversions API overview · Best practices

02 — EVENT ANATOMY

What's inside a CAPI event?

A server event combines information about the action, its time and source with data that may support matching and describe the commercial action. Requirements vary by event type and source; website events require action_source, event_source_url and client_user_agent, and user_data must contain at least one customer-information parameter.

VALUE

Purchase

WHAT IT MEANS

Describes which standard or custom action happened.

WHY IT MATTERS

The field tells Meta which kind of action the payload represents.

COMMON IMPLEMENTATION MISTAKE

Names differ between browser and server.

Meta: Parameters · Server Event Parameters

03 — STANDARD EVENTS

event_name: What happened?

event_name is required and describes the action type. Standard events provide common semantics for familiar actions; custom events cover other business-specific actions. Only use a standard name when the real action matches its definition.

PageView: Page loaded

Select a stage for a simplified example. Purchase should represent a genuinely confirmed order.

Meta: Standard and custom events · Server Event Parameters

04 — TIMING

event_time and data freshness

event_time is a required Unix timestamp in GMT and should represent when the business action actually happened—not merely when a queue was processed. Meta’s current documentation accepts event_time up to seven days in the past; older requests are rejected. That is a technical boundary, not a target delivery time.

Data freshness concerns how quickly an event becomes available after the action. Greater delay can reduce how current the signal is. Meta says sent events should be verifiable in Events Manager within 20 minutes, but this is not a promise of attribution or performance.

Event Delivery Timeline

PURCHASE
T+0BROWSER
T+0.2SERVER
T+1.0META

Server delivery delay

All default times are illustrative. No performance penalty is calculated.

Meta: Server Event Parameters · Verifying your setup

05 — MATCHING INPUTS

user_data: How matching information works

user_data contains customer information that may help Meta associate an event with an account. Current web-relevant fields can include email, phone, external_id, client_ip_address, client_user_agent, fbc and fbp where available, relevant and lawfully processed.

Meta requires normalisation and SHA-256 hashing for email, phone, name, gender, date of birth, city, state, postcode and country. Hashing external_id is recommended. IP address, user agent, fbc and fbp must not be hashed. Use Meta’s SDK or documented method—not custom cryptography.