--- title: Dotdigital slug: dotdigital docTags: createdAt: 2026-09-14T18:28:08.203Z --- Dotdigital is a marketing automation platform for email, SMS and cross-channel programs. This destination sends your Chord events and contact updates to Dotdigital server-side, over its v3 API. This destination uses **Dotdigital API v3**. Because it runs server-side it is unaffected by ad blockers and browser tracking restrictions, and it is the only surface that can write a full contact record — data fields, address book membership. For web behaviour tracking, abandoned browse and abandoned cart, which need the browser, pair this with the [Dotdigital Tag](#) destination. # Getting Started You will need: - **An API user name and password.** Create a dedicated API user in Dotdigital under **Account > Settings > Access > API users**. Dotdigital generates the username; you set the password. Create one API user for Chord rather than sharing an existing one, so it can be revoked on its own without breaking your other integrations. Dotdigital does not show the password again after you save it. - **Your region** — `r1`, `r2` or `r3`. Your Dotdigital account lives in exactly one region and it is part of every API hostname. Read it off the API endpoint shown on the same API users page. Two settings are optional: - **Address Book ID** — when set, contacts Chord creates are added to this address book. Find the ID in the URL when you open the list under **Audience > Lists**. Read the note under Consent before you set this. - **Cart URL** — your storefront's cart page, used when an event does not carry `cart_url` itself. Use the same value as the Dotdigital Tag destination so an order looks the same whichever surface reported it. # Connecting to the Dotdigital CDP Destination :::BlockQuote **Warning:** Before connecting destinations in the Chord CDP, please verify with all Destination owners that all **non-Chord CDP** configured destinations are **disabled**. Running external destinations alongside configured Chord CDP destinations **can result in duplicate events downstream.** ::: 1. Log into the Chord data platform. 2. Navigate to the CDP. 3. Click the **"Add"** button next to Destinations. 4. Select **Dotdigital** from the destination catalog. 5. Enter the destination name, your **API User Name** and **API User Password**, and your **Region**. 6. Leave **Contact Identifier** on Email unless your Dotdigital contacts are keyed on SMS, and leave **Create Contacts Automatically** on unless another system provisions your Dotdigital contacts. 7. Click **"Create"** to connect. # Using Alongside the Dotdigital Tag Destination The [Dotdigital Tag](#) destination loads Dotdigital in the browser. The two are complementary rather than duplicates, and both can run on the same Dotdigital account: - **The Tag** owns web behaviour tracking, abandoned browse and abandoned cart. Dotdigital's abandonment timer runs from the last cart update it saw in the browser, so this destination cannot drive it. - **This destination** owns the contact record, and survives ad blockers. **One thing to know before you enable both: order and cart data lands in two places.** The Tag writes into Dotdigital's own order and cart collections — the ones its abandoned-cart program and order content blocks read. Dotdigital's Events API is **not permitted** to write into those collections, so an order reported here creates a separate Insight data collection named after the event instead. That is not double-counting in Dotdigital's order reporting, but an order reported by both surfaces exists as two records in two collections. Decide which surface is your source of truth for order segmentation and content, and build against that collection. # Deduplication Every event Chord imports carries an `id` — Dotdigital's documented unique event identifier — set to the event's own message ID. If you also push events into the same Dotdigital account from another system, that is the value to deduplicate against. This is the clearer of the two surfaces: the Tag's commerce calls accept no per-call event identifier, so they can only be deduplicated on the order or cart reference, which Dotdigital does not document deduplicating on. See [Dotdigital Tag](#) for that limitation. # Event Mapping | Chord event | Dotdigital | | --------------------------------------------------------- | ------------------------------------------------------ | | `identify`, `Email Captured`, `Signed Up`, `User Created` | Contact created or updated | | `Product Viewed`, `Product List Viewed` | Event imported, with product data | | `Product Added`, `Product Removed`, `Cart Viewed` | Event imported, with cart data | | `Checkout Started` | Event imported, with cart data | | `Order Completed` | Event imported, with the order reference and cart data | | Any other `track` event | Event imported under its own name | | `Page Viewed` | Not sent — see Gotchas | Each imported event becomes a record in an Insight data collection named after the event. Dotdigital replaces non-alphanumeric characters with underscores when it names the collection, so `Order Completed` becomes `Order_Completed`. # Contacts An `identify` — and the identity-bearing track events above — create or update the Dotdigital contact. | Chord trait | Dotdigital field | | ------------ | -------------------------- | | `email` | `identifiers.email` | | `phone` | `identifiers.mobileNumber` | | `first_name` | `dataFields.firstName` | | `last_name` | `dataFields.lastName` | Both identifiers are sent when both are known, regardless of which one addresses the contact — that is how a contact who arrived by email gains an SMS channel, and the other way round. Identifiers go to Dotdigital **in plaintext**, and this is deliberate. Dotdigital has to actually deliver mail and SMS to the person, so it accepts no hashed identifier — hashing would break delivery rather than protect anything. If your security review needs to know exactly what Chord sends, that is the list above. **Mobile numbers must be in E.164 format** — `+14155550123`. A number with no country code is skipped rather than guessed at: completing it would mean assuming a country, and a wrong assumption can resolve to a real contact somewhere else. Formatting like spaces, dashes and brackets is fine; a leading `00` is treated the same as `+`. **Only **`firstName`** and **`lastName`** are sent as data fields.** Dotdigital data fields have to already exist in your account — you declare them in Dotdigital, and writing one Dotdigital does not know about does not create it. Rather than guess at your field names, Chord sends only these two and leaves the rest to you: map any other trait onto the exact data field name your account uses, using Property Mappings below. # Consent **Chord never sets a subscription status and never writes a consent record.** Both would manufacture consent out of the fact that somebody browsed a storefront. A contact Chord creates gets whatever status your Dotdigital account applies by default, and your own consent flow governs whether they become mailable. The **Address Book ID** setting is the one exception, and it is opt-in for exactly this reason: adding a contact to an address book makes them mailable in Dotdigital. Set it only where your consent flow allows it. Leave it empty to create contacts with no list membership. # Product and Cart Data Commerce events carry the same product and cart shapes the [Dotdigital Tag](#) sends, so an order looks the same in Dotdigital whichever surface reported it. See that destination's Product and Cart Data section for the full field tables. That includes its **Fields Dotdigital requires** table. Those requirements are Dotdigital's, not the browser's, so they apply here too — an event missing one is rejected with a `422` and, unlike a rate limit, is not retried. Everything else your event carried is preserved alongside the commerce shape, so you can segment on your own properties. The raw `products` array is replaced by the Dotdigital-shaped one rather than sent twice. # Property Mappings You can map any event property onto a destination field from the connection's mapping configuration. Mapped properties use a **bare path** — `properties.customer_type → customer_type`. Two ways this is useful here: - **Filling a Dotdigital data field.** Map a trait onto the exact data field name your Dotdigital account declares, so a contact update writes it. - **Reshaping event data.** Mappings are applied before the payload is built, so a mapping that rewrites `properties.sku` changes what Chord reads for the product's SKU. Everything an event carries beyond the commerce shape is imported as event data already, so a custom property does not need a mapping to reach Dotdigital's Insight data collection — mappings are for renaming and restructuring. # Gotchas **Every event needs a contact that already exists in Dotdigital.** This is Dotdigital's rule, not Chord's: the Events API rejects an event whose contact it does not know. That is why **Create Contacts Automatically** is on by default — Chord creates or updates the contact immediately before importing each event. Turn it off only if another system provisions your Dotdigital contacts, and be aware that with it off, events for contacts Dotdigital does not know are rejected. It also means two requests per identified event rather than one, which counts against your Dotdigital rate limit. Your limit depends on your package and is shown under **Account > Settings > Access > API rate limits**. **Anonymous events are not sent.** An event with no email address and no valid E.164 mobile number is skipped, because Dotdigital has no anonymous contact to attach it to. This is normal for storefront browsing traffic before a shopper identifies themselves — the [Dotdigital Tag](#) is the surface that captures pre-identification behaviour. **Page views are not sent.** Dotdigital's own web behaviour tracking owns page views and writes them into a first-party collection that its Events API is not permitted to write into. A server-side page view could only land in a parallel collection duplicating data Dotdigital already holds in the place its features read from. Connect the [Dotdigital Tag](#) for page views. **Custom events need the CXDP package** on your Dotdigital account, as does the event import generally. Without it Dotdigital cannot accept imported events. **Nine collection names are reserved** by Dotdigital for its own features: `cartInsight`, `catalog`, `consentInsight`, `easyEditorExtensions`, `nostoEmailCampaigns`, `orders`, `productCategories`, `webInsight` and `wishList`. An event whose name matches one is skipped and logged. **A successful response means accepted, not stored.** Dotdigital's event import is asynchronous and answers `202 Accepted`. Per-event validation problems surface in Dotdigital's own import status rather than in the response Chord sees, so a clean log entry in Chord is weaker evidence here than it would be for a synchronous API. Check the Insight data collection in Dotdigital when verifying a new connection. **Data subject erasure is supported, with a 30-day delay.** Chord can action a deletion request against Dotdigital, which deletes the contact. Dotdigital then holds it in your account's recycle bin for **30 days** before removing it permanently, and an account administrator can recover it within that window. Chord has no way to empty the recycle bin, so if your statutory deadline is shorter than Dotdigital's 30 days, empty it yourself in Dotdigital under the recycle bin. Contacts who were already suppressed are the exception — their data fields and Insight data are removed immediately and cannot be recovered. Erasure is addressed by email address only. Dotdigital's own contact ID is a key it assigns rather than one Chord knows, so a deletion request that names only a user ID is skipped rather than resolved against it. **Updated 9 September 2026**