Meta Conversions API for affiliate tracking

Meta Conversions API (CAPI) sends event data from a server to a Meta dataset. For an affiliate buyer, that can connect an approved sale or lead to the Meta campaign that produced the click.

“Facebook CAPI” is an older search phrase for the same Meta Conversions API. Use Meta’s current product name when you configure the connection.

The important distinction is where each request goes. An affiliate network postback sends a verified conversion to your tracker. CAPI sends a provider-specific event from your server to Meta. You need both hops when the tracker is the system that receives the conversion first.

Planning the whole campaign? Start with Facebook ads for affiliate marketing. This guide covers the separate Meta event-delivery layer. If you control the store checkout, use the ecommerce ad-tracking guide to identify the order evidence before configuring delivery.

Facebook postback URL versus Meta Conversions API

If you searched for a “Facebook postback URL,” identify the direction first. An affiliate network can call a tracker URL such as Tracked's /postback after a sale. Meta receives server events through the Conversions API for a configured dataset. Pasting the Tracked callback URL into a Meta event field does not send that event to Meta.

The practical sequence is ad click → Tracked offer click → advertiser conversion → Tracked inbound postback → separately configured Meta server event. Keep the original click and approved conversion identity through that sequence, then inspect both Tracked's event and Meta's provider response. Tracked's current Meta delivery boundary is described below; its dataset connection and test event are not proof that every affiliate postback is automatically forwarded.

What an affiliate CAPI flow needs

The flow starts with a Meta ad click and ends with an event that Meta can process.

1. Capture the click context on the landing-page visit.
2. Carry the campaign’s click reference into the offer or affiliate network.
3. Receive the approved conversion through the network’s server callback.
4. Build a Meta event with the right event name, time, action source, and data.
5. Send the event to the dataset through the Conversions API.
6. Check the provider response and Events Manager diagnostics.

Meta’s Conversions API documentation describes server, website-platform, and CRM connections that send events to Meta. It is not a generic postback URL and does not use Google’s click-conversion format.

For affiliate campaigns, the inbound callback commonly carries a click reference, payout, currency, and timestamp. Tracked’s dispatcher accepts click_id, payout, currency, timestamp, and optional conversion_type (with type as an alias). That endpoint is not an outbound Meta API.

In Tracked, the untyped callback records the primary conversion and its payout. An explicitly typed callback is a secondary funnel signal and records zero payout, even if the sender includes payout. Choosing Purchase for a separate Meta payload does not mean adding that word as the Tracked callback type.

Build a useful server event

Start with the business event that the network actually confirmed. A lead, approved sale, refund, and rejected lead should not all become Purchase just because Meta has a standard event with that name.

A website event needs the right event and customer-data fields:

• event_name, such as Lead or Purchase;
• event_time as a Unix timestamp in seconds;
• action_source: "website";
• event_source_url for the page where the event occurred;
• user_data, including the browser’s client_user_agent and only permitted matching fields;
• custom_data for value, currency, order ID, or other event context.

Meta’s current parameter reference lists action_source, event_source_url, and client_user_agent as required for website events. A real browser user agent belongs in user_data; do not invent it when a network callback lacks that evidence.

Use the conversion timestamp from the verified source. Do not substitute the time when your tracker happened to receive a retry.

If you send email, phone, or other customer information, follow Meta’s customer-information parameter guidance. Normalize the values and SHA-256 hash fields such as email and phone where required. Do not hash fbc, fbp, IP address, or user agent when supplying those Meta fields. Send only permitted data, and keep raw personal data out of URLs and callback templates.

Browser identifiers have a different role. Reuse real _fbc and _fbp cookie values as fbc and fbp when available and permitted. Meta’s click-ID guidance also allows correctly formatted fbc from a real, observed fbclid when _fbc is unavailable. That requires the actual click value and its first-observed time—not a made-up identifier or UTM label. Preserve fbclid case exactly.

These rules describe Meta’s implementation requirements. Tracked’s supplied-event route does not promise to collect or construct the matching fields for you.

Deduplicate Pixel and server events

If the same conversion reaches Meta through both the browser Pixel and CAPI, Meta’s recommended approach is a shared stable event identifier and event name. The browser uses eventID; the server payload uses event_id. Meta’s deduplication guidance explains this approach and the limits of alternative matching methods.

Generate one ID when the conversion is created and keep it unchanged across retries. An affiliate order ID can be a good source when it is stable and unique. A random ID generated separately for the Pixel and CAPI request will not deduplicate those two events.

Deduplication is not the same as retry protection. Your tracker still needs an idempotent rule for repeated affiliate callbacks, while Meta needs matching identifiers for overlapping browser and server events.

Where Tracked is today

Status: Meta conversion delivery is partial and the automated Tracked-to-Meta workflow is in development. The current integration can connect a Meta account, resolve or create a dataset, and send a synthetic PageView test event with a test code. The backend also has a generic authenticated CAPI event route for a caller that supplies the event payload.

The current app does not expose a finished workflow that takes every Tracked conversion postback, maps it to a Meta event, and delivers it automatically. Tracked does not currently promise that it hashes your customer data, builds fbc, chooses a shared Pixel event ID, or deduplicates a browser event for you.

That boundary is useful when planning a campaign. You can verify the Meta connection and test-event path, but treat production conversion delivery as a capability to confirm before relying on it for optimization.

A practical setup and check sequence

1. Connect the right dataset. Confirm that the Meta account and dataset belong to the ad account running the campaign.
2. Name the event contract. Decide which approved network states map to Lead, Purchase, or a custom event.
3. Preserve the click context. Check the final offer request and the network record, not only the first tracking URL.
4. Create one conversion ID. Reuse it for retries and for Pixel/CAPI deduplication when both channels send the event.
5. Validate data handling. Hash permitted customer fields before sending them, and record consent decisions at the boundary that owns them.
6. Run a test event. Use Meta’s Test Events tool or a provider-generated test code. A test response proves that the request reached the API; it does not prove campaign attribution.
7. Check the whole chain. Verify the inbound callback, click match, event payload, provider response, and reporting state separately.

For the tracker-side callback mechanics, see the postback URL conversion tracking guide. Before buying traffic, use the Facebook landing-page checklist to inspect the destination and click handoff. For browser-versus-server tradeoffs, see client-side versus server-side tracking. Google’s path is separate: the Google Ads offline-conversions guide covers click-based uploads rather than Meta CAPI.

Frequently asked questions

Does Tracked automatically send affiliate conversions to Meta?

Not as a finished production workflow today. Tracked can connect a Meta dataset, send a test PageView, and accept a supplied CAPI event through its backend route. Automatic delivery of Tracked conversion postbacks to Meta remains partial and in development.

Is a Meta postback the same as Conversions API?

No. An affiliate postback is an inbound callback to the tracker after the network confirms a conversion. Conversions API is the outbound, Meta-specific server event request that follows when an implementation is configured to send it.

Do I need event_id when I use the Pixel and CAPI together?

Use Meta’s recommended shared-event-ID approach when both channels describe the same conversion: the browser eventID must match server event_id, and the event names must match. Meta documents alternative methods with limitations. Do not assume that two requests with the same payout or ad click ID will deduplicate.

Should I send raw email addresses or phone numbers?

No. If your approved implementation sends those fields, follow Meta’s normalization and hashing rules before the request leaves your system. Send only data covered by your measurement and consent requirements.

Does a successful API response prove that Meta attributed the sale?

No. Separate transport acceptance, event processing, match quality, and campaign reporting. Confirm each state in the provider tools before treating the conversion as a usable optimization signal.

Sources reviewed October 4, 2026: Meta’s Conversions API reference, parameter guide, click-ID guide, deduplication guide, and setup-verification guide.

Start free — early access. Use your invite or request access, then map one campaign’s callback and Meta delivery boundaries before relying on them for optimization.