Universal CAPI for performance marketing: what to verify

A universal conversion API should record one verified conversion and send a provider-specific event to each configured network. “Universal” does not mean every network uses the same payload. The product still needs to map identifiers and events, respect consent, handle retries and duplicates, and show the result for each provider.

Tracked has some provider-specific delivery workflows, but its universal multi-network conversion layer is not available today. This guide explains what to evaluate and where Tracked stands.

What does CAPI mean?

CAPI usually means Conversions API: a provider-supported interface for sending conversion events from a server rather than relying only on browser code.

The label is most closely associated with Meta, but the underlying pattern appears across ad platforms under different names:

• a server-to-server postback;
• an offline conversion upload;
• a conversion event API;
• an events endpoint;
• a provider-specific callback URL.

These are related mechanisms, not one shared protocol. Each provider defines its own identifiers, credentials, event vocabulary, consent fields, limits, and response format.

Google Ads, for example, accepts offline click conversions associated with identifiers such as gclid, gbraid, and wbraid. Its official offline conversion documentation also defines conversion actions, values, currencies, order IDs, consent, batching, and diagnostics.

Meta’s Conversions API is a server-to-server path for web, app, and offline events. A direct integration must construct the expected server event, authenticate it, test delivery, and handle deduplication when the same event also arrives through browser tracking. Meta’s official direct-integration course covers those implementation concerns.

Calling both systems “CAPI” is convenient. Treating them as interchangeable is not.

What a universal conversion layer must do

A useful cross-network conversion layer needs at least six parts.

1. Preserve the network click identifier

Attribution begins when a visitor arrives. The tracker must capture the traffic source’s click identifier and associate it with the Tracked click.

The parameter is not always named click_id. Google commonly uses gclid, gbraid, or wbraid. Other platforms use their own parameter names. A configurable tracker should not require every provider to fit one hardcoded field.

If the identifier is lost between the ad click, landing page, offer, and conversion, the later server event may be valid but unattributable.

2. Accept a verified conversion

The conversion should come from the system that can confirm it happened. That might be an advertiser, affiliate network, checkout backend, CRM, or lead-validation service.

The inbound event needs a stable reference to the original click. It may also carry:

• conversion type;
• payout or revenue;
• currency;
• order or conversion ID;
• event timestamp;
• test status.

A browser button click is not the same as an accepted lead or paid order. The universal layer should preserve that difference.

3. Translate the event for each provider

One campaign may call an event purchase. Another provider may expect a configured action ID. A native campaign may use a custom event name.

The delivery layer must map a canonical conversion to the exact provider destination without silently inventing a fallback. A missing mapping should produce a visible skipped result, not a successful-looking request with the wrong event.

4. Apply consent and data rules

Server-side delivery does not remove privacy obligations. The layer still needs to decide which fields may be stored or sent, under which consent state, and for how long.

The safest design sends only what the provider and configured measurement purpose require. A click-ID conversion upload is not automatically an enhanced-conversions implementation, and an anonymous visitor profile is not automatically a known customer identity.

5. Deliver reliably

Provider APIs fail. Requests can time out, rate limits can apply, credentials can expire, and a provider can reject one event in an otherwise valid batch.

A serious conversion layer needs:

• bounded retries for transient failures;
• idempotency or deduplication safeguards;
• timeouts;
• batch limits;
• test-event handling;
• provider response capture;
• a permanent failure state.

“Request sent” is not the same as “conversion accepted.”

6. Expose diagnostics

Media buyers need to answer four questions quickly:

1. Did Tracked record the conversion?
2. Which click and campaign did it match?
3. Was feedback attempted for the traffic source?
4. What did that source return?

Without those answers, adding more integrations can create more uncertainty rather than better optimization signals.

Where Tracked is today

Tracked supports Google Ads offline click-conversion uploads through the Data Manager API for configured conversion actions. The upload uses eligible gclid, gbraid, or wbraid evidence and consent checks. This is click-ID delivery, not enhanced conversions for leads.

Tracked's Meta integration can connect an ad account, resolve a dataset, send a test event, and expose a generic route for caller-supplied events. It does not automatically map every stored Tracked conversion to Meta, and it does not provide a finished conversion-delivery workflow with an operator UI for mapping and deduplication. The universal multi-network layer is in development.

Tracked also supports configured server-to-server postbacks to Taboola and NewsBreak. Those are provider-specific paths, not one shared CAPI endpoint.

Inbound postbacks are a separate step: they let a network or advertiser report a conversion to the original Tracked click. Receiving a postback does not by itself send that conversion back to an ad platform.

Questions to ask any “universal CAPI” product

Before choosing a tracker or conversion-delivery product, ask:

1. Which providers have a working production delivery path today?
2. Is each connection a native API, a configurable postback, or only a logo?
3. Which click identifiers does each provider require?
4. Are event names or action IDs mapped per campaign?
5. How are consent and restricted fields handled?
6. Are browser and server events deduplicated when both are sent?
7. What happens after a timeout, rate limit, or partial rejection?
8. Can a buyer see the provider response for one conversion?
9. Can earlier conversions be backfilled after setup?
10. Does the product state clearly where support is partial or planned?

The answers are more useful than the number of logos on an integrations page.

The practical rule

Treat universal CAPI as a provider-by-provider contract. Capture the right click identifier, accept a verified conversion, translate it deliberately, send only allowed data, and expose the delivery result.

Tracked keeps the hosted page, route, conversion record, report, and editor in one campaign workspace. For provider feedback today, use the specific Google Ads, Taboola, or NewsBreak path that matches the campaign; a universal multi-network layer remains in development.

Tracked's current provider boundaries are listed above. Check the exact delivery path, required identifiers, consent rules, and provider response before treating a conversion as delivered.

Frequently asked questions

Is Universal CAPI available in Tracked?

Not as a universal multi-network workflow. Google Ads offline click-conversion uploads are available through the Data Manager API for configured conversion actions. Meta account and dataset setup, test events, and caller-supplied event requests do not equal automatic delivery of Tracked conversions. The universal layer is in development.

Is every conversion API the same protocol?

No. Providers define different identifiers, event vocabularies, credentials, consent fields, limits, and response formats. A universal layer has to translate and validate those provider-specific contracts rather than send one generic payload everywhere.

Does server-side conversion delivery replace browser tracking?

Not completely. Browser events can describe page interactions that a backend does not observe, while server events can confirm business outcomes. A reliable design assigns each event to the source that can verify it and deduplicates overlapping paths.

Start free and review your conversion delivery setup.