> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/activate/event-streaming/deduplication.md).

# Deduplication

Chord delivers every event at least once. In rare cases, the same event can arrive at a destination more than once. This page explains why, and how to keep duplicates out of your data.

## Delivery guarantee

Chord retries when something fails, so an event is never lost to a short outage. The trade-off is that a retry can occasionally deliver an event twice. Common causes:

* Chord restarts a processing instance, such as during a release, before it records its progress.
* A network pause makes Chord send an event again.
* A source retries after it never got a confirmation.
* A temporary failure in a downstream service causes a replay.

Most customer data platforms work this way.

## How duplicates are handled

Chord doesn't remove duplicates itself. The destination does. Chord keeps each event's `messageId` from start to finish and passes it to every destination. If the source didn't set one, Chord makes one when the event arrives. The same `messageId` goes to every destination, and it shows in [Live Events](/activate/event-streaming/live-events.md).

Destinations use that ID to spot duplicates:

* **Data warehouses** such as Snowflake and BigQuery: deduplicate in your warehouse queries on `messageId`, or contact Chord support.
* **Marketing and ad tools** that take an API call, such as Klaviyo: Chord sends the `messageId` to Klaviyo as its unique ID, so Klaviyo can ignore repeats.

The destination is the right place for this. It knows what it has already received. It also keeps Chord fast, because Chord doesn't have to look up every event in a list first.

## Browser and server pairs

Many ad platforms get each event twice on purpose, once from the browser and once from the server. See [Browser and server destinations](/activate/event-streaming/browser-and-server-destinations.md). The platform removes the repeat when both copies carry the same event ID.

For example, on Meta, the Order Completed event uses the order ID as its event ID in both Meta Pixel and Meta Conversions API. Meta counts the order once.

Each vendor page in the [destination catalog](/activate/event-streaming/destinations.md) says how that vendor handles its two versions.

{% hint style="info" %}
Duplicates can also come from tracking that runs outside Chord, such as a pixel left in your theme. See [Connect a destination](/activate/event-streaming/connect-a-destination.md).
{% endhint %}

## Functions that write to other systems

Because of retries, a [function](/activate/event-streaming/functions.md) can run more than once for the same event. That's harmless when the function only changes the event or drops it. If it writes to an outside system, such as creating an order or sending an email, make the write safe to repeat. Send `event.messageId` as an idempotency key:

```javascript
export default async function (event, { fetch }) {
  await fetch("https://api.example.com/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Idempotency-Key": event.messageId,  // stops a second write if the event is replayed
    },
    body: JSON.stringify({ /* ... */ }),
  });
  return event;
}
```

Without a key, a replayed event can make the write happen twice.

## Questions

For help with delivery or deduplication, contact <help@chord.co>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/activate/event-streaming/deduplication.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.