TerradsTerrads
← Glossary

Conversions API

  • Also called CAPI, Meta Conversions API
  • Updated October 31, 2026

The Conversions API (CAPI) sends events such as purchases, leads and sign-ups to Meta from your server, app, website platform or CRM, instead of from the visitor's browser. Meta processes them like Meta Pixel events, for attribution, ad delivery and reporting. Meta recommends running it alongside the Pixel, sending the same events through both with an ID that lets Meta drop the duplicates.

How does Meta define the Conversions API?

From Meta's developer overview:

The Conversions API is designed to create a connection between an advertiser's marketing data (such as website events, app events, business messaging events and offline conversions) from an advertiser's server, website platform, mobile app, or CRM to Meta systems that optimize ad targeting, decrease cost per result and measure outcomes.

The same page says server events "are processed like events sent using the Meta Pixel" and "may be used in measurement, reporting, or optimization in a similar way as other connection channels." If a Pixel is already on your site, Meta says you can set it up for website events "in one click from Meta Events Manager, with no code, configuration, or setup fees."

Do you still need the Meta Pixel?

Meta recommends both. Its best practices say: "Use the Conversions API in addition to the Meta Pixel, and share the same events using both tools." The server catches "website events that the Pixel may lose due to network connectivity issues or page loading errors", plus events "that occur offline or at a later time". Meta's implementation guide lists three setups:

SetupWhat goes whereMeta's verdict
Redundant"all events via both Pixel and Conversions API"Recommended: "performance comparable to or better than using only the browser Pixel"
SplitSome events by Pixel, others by the API"not as optimal as a redundant setup"
Server-onlyEvery event through the API, none from the browser"Implement either a redundant setup or a split setup before switching to this approach."

How does Meta avoid counting an event twice?

By deduplication. For a match, the Pixel's eventID must equal the API's event_id, and the Pixel's event must equal event_name. When Meta finds the same pair from both sources for one Pixel ID within 48 hours, it says "we discard the subsequent events." Meta suggests an order number or transaction ID as the event_id. If you never send the same event through both, Meta says you "do not need to set up deduplication for those events."

What does Event Match Quality measure?

Event Match Quality (EMQ) is Meta's score for server events, "a measure of how effective your server event's customer information parameters may be at matching events to a Facebook account", per Meta's setup checks. It runs from 1 to 10, and Meta recommends you "aim for an Event Match Quality score of 6.0 or higher." The match matters because "You can use only matched events for ads attribution and ad delivery optimization"; unmatched events still count "for basic measurement". Meta's examples of high-quality customer information are email, IP address, first and last name, and phone number. EMQ "is currently available only for web events."

What it means for your ads

  • Send purchases and leads from your server as well as the browser, with the same event name and ID on both and the same Pixel ID.
  • Send events as they happen. Meta recommends sending them "as soon as they occur and ideally within an hour", and one event_time more than 7 days old fails the whole request: "we return an error for the entire request and process no events."
  • For value optimization, add value and currency to the event in both the Pixel and the API, and keep them consistent.
  • Server events feed more than reports. Meta says every action_source value enables "ad measurement and custom audience creation", so a store or phone sale can build a custom audience too.
  • To measure what the server events add, Meta's best practices suggest a conversion lift study, to "Understand the incremental performance impact of using server events."

Common mistakes

  • Giving different events the same event_id. Meta's guide asks that each one have "its own event_id. This ID should not be shared with other events."
  • Sending raw emails or phone numbers. Meta's systems "are designed to not accept customer information that is unhashed Contact Information"; its Business SDK hashes them for you.
  • Mixing up EMQ and match score. Match score rates an uploaded customer list; EMQ rates the customer information on each server event. The phone rule is the same for both: include the country code "even if all of your data is from the same country."

Sources

Meta updates its developer documentation without notice, so check the source before changing an integration.

Terrads makes ads that differ in concept and layout, so when your server events credit sales to each ad, you are comparing different ideas.