Meta CAPI Sending Duplicate Purchase Events: Common Causes and Fixes
When CAPI sends the same Purchase event more than once, your server is delivering the same purchase to Meta multiple times. This is a server-side duplication problem, distinct from browser and server deduplication. The cause is usually repeated server requests, webhook retries or multiple integrations sending the same event.
Table of Contents
- 01.Server-side duplication is different
- 02.What to check first
- 03.Duplicate server requests and webhook retries
- 04.Multiple integrations
- 05.Server-side GTM and duplicate paths
- 06.Use a unique event ID
- 07.How to test it
Server-side duplication is different
This is not the browser and server counting the same conversion twice, which deduplication handles. This is the server itself sending the same Purchase event more than once. Each duplicate server request without a unique event ID can be counted as a separate purchase, inflating your data.
What to check first
- Check whether a single order triggers more than one CAPI request.
- Look for webhook retries that resend the same order event.
- Check for multiple integrations sending Purchase to the same dataset.
- Confirm each Purchase event carries a unique event ID like the order ID.
- Review server logs for repeated requests with the same order identifier.
Duplicate server requests and webhook retries
Webhooks can fire more than once. Ecommerce platforms often retry a webhook if they do not receive a timely success response, which can send the same order event to your server multiple times. If your server processes every webhook as a new CAPI request, the same purchase is sent repeatedly. Your server should recognize a repeated order and avoid resending it, typically by checking the order ID before sending.
Multiple integrations
If you run more than one integration that sends Purchase to CAPI, the same order can be sent by each one. A native platform integration plus a custom CAPI implementation or server-side GTM plus a direct integration can both send the same purchase. Audit every path that can send a Purchase event to your dataset and confirm only one should fire per order.
Server-side GTM and duplicate paths
Server-side GTM is a common source of duplication when it runs alongside another CAPI implementation. If both the server-side GTM container and a separate integration handle the same purchase event, Meta receives it twice. Confirm which path is responsible for sending Purchase and disable or deduplicate the others.
Use a unique event ID
Each Purchase event should carry a unique event ID, typically the order ID. A unique event ID lets Meta recognize repeated sends of the same purchase and avoid counting them separately. If your server sends the same order ID on every retry, Meta can deduplicate the server-side duplicates. Without a unique ID, each request can be counted as a new purchase.
How to test it
- 1.Place a single test order and count the CAPI requests your server sends.
- 2.Check server logs for repeated requests with the same order ID.
- 3.Confirm each Purchase event carries the order ID as the event ID.
- 4.Identify and disable any duplicate integration sending the same purchase.
- 5.Confirm one CAPI Purchase reaches Meta per order after the fix.
Frequently Asked Questions
How is this different from browser and server duplicate conversions?
Browser and server duplicates are two delivery paths for one event, handled by deduplication. Duplicate CAPI Purchase events are the server itself sending the same purchase more than once, usually from webhook retries or multiple integrations.
Will a unique event ID stop duplicate CAPI Purchase events?
It helps Meta recognize repeated sends of the same purchase and avoid counting them separately. You should also stop the duplicate requests at the source by handling webhook retries and removing duplicate integrations.
Need help applying this to your business?
PPC, Conversion Tracking, CRM and Automation Specialist. Helping businesses generate qualified leads with Google Ads, accurate tracking and automated follow-up.
Related Guides
Meta CAPI Purchase Events Missing: How to Trace the Server-Side Event Flow
A missing CAPI Purchase is a server-side flow problem. Confirm the order triggers the server logic, confirm the payload carries the order data and check the CAPI response.
Meta Pixel and CAPI Counting the Same Conversion Twice: How Deduplication Works
Pixel and CAPI sending the same event is expected. The goal is deduplication through a matching event name and event ID, not removing one of the delivery paths.
Meta CAPI Event ID Missing or Incorrect: Why Deduplication Can Fail
The event ID is the link between the browser and server events. Use a stable identifier like the order ID, generate it once and confirm the same value is present on both paths.