Dotdigital

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 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 log into the chord data platform navigate to the cdp click the "add" button next to destinations select dotdigital from the destination catalog enter the destination name, your api user name and api user password , and your region 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 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