Step 11 — Send it back to Meta
A destination, a rule, and a test event you can find in Meta's Test Events tab — the end of the golden path.
This is what the previous ten steps were for. Atribu knows which conversions are real and what they were worth; Meta's optimizer does not, unless you tell it. Conversion Sync is that channel.
Two objects are required, and both are silent when missing
A destination with no rules sends nothing, and an export against a profile
with neither succeeds and ships zero — with no error anywhere. There is no
default mapping. That is why readiness scores them as two separate steps,
capi_destination_enabled and capi_rules_enabled.
Open Conversion Sync
The checklist there walks the same four things this page does.
Add the destination
Pick the Meta connection and the dataset (pixel) id from Events Manager. For Google Ads, the conversion action resource name.
Create a signal rule
Choose the conversion definition (step 9's cash one), the destination, and
the Meta event name — Purchase for money. Choose how value is sent: the
conversion's own amount, a fixed value, or none.
Send a test event and find it in Meta
Copy the test_event_code from Events Manager → Test Events, send the
test, and watch it arrive. Then activate the rule.
Full walkthrough, including privacy modes and skip reasons: Conversion Sync.
Four calls, in this order. Scopes: exports:write for the configuration and
the test, attribution:write for the export itself. exports:write is not
granted by any OAuth connect scope — a workspace admin opts a key into it.
curl -sX POST https://api.atribu.app/api/v1/exports/destinations \
-H "Authorization: Bearer atb_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"destination": "meta_capi",
"connection_id": "0d0e6c8a-…",
"meta_pixel_id": "1234567890",
"enabled": true
}'curl -sX POST https://api.atribu.app/api/v1/exports/rules \
-H "Authorization: Bearer atb_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Payment → Purchase",
"source_kind": "conversion_definition",
"source_ref_id": "6f1c…",
"destinations": { "meta_capi": { "enabled": true } },
"platform_event_name_overrides": { "meta_capi": "Purchase" },
"meta_custom_event_type": "PURCHASE",
"value_mode": "event_value"
}'source_ref_id is a conversion_definitions id from
GET /api/v1/goals/definitions — not an outcome_definitions id, which is a
CRM pipeline-stage label and a different thing entirely.
curl -sX POST https://api.atribu.app/api/v1/exports/test \
-H "Authorization: Bearer atb_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"destination_id":"…","test_event_code":"TEST12345","rule_id":"…"}'Search the returned event_id in Events Manager → Test Events. Passing
rule_id makes the test borrow that rule's event name and privacy override, so
it exercises the rule you are actually verifying. Capped at 5 sends per profile
per minute.
curl -sX POST https://api.atribu.app/api/v1/exports \
-H "Authorization: Bearer atb_live_YOUR_KEY"202 with a batch id. Poll GET /api/v1/exports/{id}, and read
GET /api/v1/exports/ledger for per-delivery detail. A non-empty ledger is
the proof the four steps worked.
`replay_queued` is not a delivery
Every mutation here answers with replay_queued / replay_error. It says a
pass was asked for — never that anything shipped. The ledger says that.
Ask a human first
require_approval: true on POST /api/v1/exports mints an approve
hand-off instead of exporting, and answers 202 having
written nothing: your human sees exactly what would be sent, approves in a
signed-out browser, and your agent polls the same result back. The MCP tool
send_meta_conversions mints it too — required whenever the caller is not a
workspace owner or admin, and available to any caller that asks for it.
Over MCP
configure_meta_capi does steps 1 and 2 in one tool and send_test_event does
step 3 (#1058). Both take mode: "preview" first — worth using here, because a
destination is the one object on this page you cannot truly delete.
Why the test event matters more than it looks
The test payload carries the same atribu_src marker a production event
carries, so it actually fires the Custom Conversion your rule created. A test
that skipped it would fire the pixel and not the conversion — the most
misleading possible result while verifying a setup.
quality_warning is non-null when the profile's match-quality policy would
block a real event carrying only what a test carries (an IP and a user agent).
The test still sends: one that could not run under a strict policy would prove
nothing.