Send Facebook Conversion Events From Your Server

The useful answer

Browser-based Meta pixels can miss conversions when browsers block third-party cookies or tracking scripts. If your measurement depends only on the pixel, some purchases and leads never reach your ad account. The useful takeaway is to send conversion events directly from your server to Meta's Conversions API (CAPI), so measurement survives browser restrictions. CAPI works alongside the pixel; it does not fully replace it.

How the mechanism works

Your server sends an HTTP POST to the Graph API events endpoint for a specific Meta pixel. The payload includes an access token, event name, event time, a unique event ID, and hashed user data such as email or phone. Meta matches the event to your ad account and deduplicates repeated event IDs within a 24-hour window. If you send the same purchase from both the pixel and your server with the same event ID, Meta counts it once.

Terms used here: system user is a non-personal Business Manager account used to authenticate API calls. user_data is the object containing customer identifiers. event_id is your own unique identifier for a conversion, used for deduplication.

Worked configuration

Create a system user in Meta Business Manager and generate an access token with the ads_read and ads_management permissions. Confirm the current endpoint path, permission names, and rate limits in Meta's official Marketing API documentation, because these can change.

Example payload structure. Placeholders in angle brackets must be replaced with your own values.

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1735689600,
      "event_id": "order_2026_00123_unique",
      "user_data": {
        "em": [""],
        "ph": [""]
      },
      "custom_data": {
        "value": 89.00,
        "currency": "USD",
        "content_ids": ["sku_blue_widget"],
        "content_type": "product"
      }
    }
  ],
  "access_token": ""
}

Hash email and phone with SHA-256 before sending. Meta's documentation defines the accepted formats and normalization rules; sending unhashed personal data can be rejected or violate privacy policy. event_time is a Unix timestamp. Events older than 24 hours are usually not attributed.

Sending the request

Run this from your server or a command-line shell, not from a browser.

curl -X POST "https://graph.facebook.com///events" \
  -H "Content-Type: application/json" \
  -d '{"data":[{"event_name":"Purchase","event_time":1735689600,"event_id":"order_2026_00123_unique","user_data":{"em":[""],"ph":[""]},"custom_data":{"value":89.00,"currency":"USD"}}],"access_token":""}'

Required permissions: the access token must belong to a system user with roles that allow advertising access on the ad account tied to the pixel. Expected check: a successful response includes an events_received count. Risk: if you omit test_event_code, the payload is treated as production data and can influence attribution and ad spend optimization.

Testing before production

Add "test_event_code": "" to the payload and obtain the test event code from Events Manager. Send the payload, then open Events Manager and check the test events tab to confirm arrival and deduplication. Only remove the test flag after you verify delivery. Long-lived access tokens still expire and must be refreshed; if authentication lapses, delivery can stop without an obvious error.

Limits and common mistakes

Issue	Behavior or consequence
Reusing one event_id for unrelated events	Meta deduplicates by event ID within 24 hours, so distinct conversions can be dropped as duplicates.
Short-lived user tokens	Use a Business Manager system-user token instead; user tokens expire sooner and can break server-to-server delivery.
Omitting event_time	Events may not be attributed correctly because Meta cannot place them in the attribution window.
Sending unhashed PII	Email and phone must be SHA-256 hashed; unhashed personal data is rejected or violates policy.
Ignoring consent signals	Privacy law may require user consent before processing conversion data, regardless of collection method.
Assuming CAPI replaces the pixel	CAPI complements the browser pixel; browser events still capture interactions that occur entirely in the browser.

Practical verification

1. Inspect the access token with Meta's Access Token Debugger to confirm scopes and expiration before writing integration code.
2. Send a test payload with test_event_code enabled.
3. Open Events Manager and verify the event appears in the test events view.
4. Send the same event ID from the pixel and server to confirm Meta counts it once.
5. Check Meta's current Marketing API documentation for the exact endpoint path, permission names, and rate limits before deploying to production.

There is no rollback for an event already sent to Meta. To stop delivery, cease sending requests and rotate or revoke the access token if it is compromised.