Microsoft CAPI

the microsoft conversions api (capi) is a server side integration that sends event data directly from chord cdp to microsoft advertising's servers unlike the bing ads uet tag (which runs in the browser), the conversions api operates in cloud mode — events are sent server to server, making them immune to ad blockers and browser tracking restrictions microsoft recommends using the conversions api alongside the uet tag for maximum data coverage when both are configured, microsoft automatically deduplicates events using the eventid field use this destination if you run paid media through microsoft advertising you want improved signal reliability independent of browser limitations or ad blockers you want to support microsoft's automated bidding and optimization with high quality server side event data getting started this is a cloud mode destination you will need uet tag id — found in your microsoft ads dashboard under conversion tracking > uet tags we recommend creating a dedicated tag for the conversions api access token — select "use conversions api" on your uet tag in the microsoft ads dashboard to generate a token contact your microsoft account manager if this option is not available site url — your storefront url, e g https //www example com optional in general , but required for back end (server side) connections microsoft rejects events with an empty eventsourceurl , and server side events carry no page url, so this value is used as the fallback browser connections don't need it (the event's own page url is used) without it, back end purchase events are rejected with a 400 validationerror connecting to the microsoft conversions api 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 microsoft conversions api from the destination catalog enter the destination name, uet tag id , and access token click "create" to connect event architecture microsoft capi requires a pageload event to establish page context chord cdp handles this automatically page events send a single pageload event track events send a pageload + custom event pair, linked by a shared page load id this means microsoft receives the page context needed for accurate attribution without any additional configuration events event mapping by default the event action ( eventname ) sent to microsoft is the chord event's own name (e g order completed ) this matches the bing uet device mode pixel, which sends the raw event name, so the two surfaces can share a single conversion goal recognized commerce events additionally get a pagetype chord event page type product viewed product products searched searchresults product added cart checkout started cart order completed purchase order placed purchase (other track events) (none) page and track events are forwarded identify and screen events are ignored overriding the event action the event mapping config setting overrides the event action for specific events unmapped events keep the raw name default, so this is purely additive use it when a conversion goal expects a different action string — for example a customer who prefers snake case, or a goal keyed on order completed { "order completed" "order completed", "product added" "product added" } goal matching in microsoft ads is case sensitive , so the value must match the goal's event action rule exactly common event fields these fields are included on every event sent to microsoft microsoft field chord source (priority order) notes eventtype (derived) pageload or custom eventid messageid + suffix pl for page load, ce for custom event eventtime timestamp converted to unix seconds eventsourceurl page url > context page url > properties url referrerurl page referrer > context page referrer pagetitle page title > context page title > properties title user data pii fields are sha256 hashed using microsoft specific normalization rules before sending microsoft field chord source (priority order) notes em (email) properties email > context traits email microsoft specific hashing dots removed from user portion, +aliases stripped, lowercased, sha256 ph (phone) properties phone > context traits phone validated, normalized to e 164 format, sha256 hashed invalid phones are silently dropped externalid userid sha256 hashed (lowercased) anonymousid anonymousid not hashed — microsoft uses as guest uuid clientuseragent context useragent not hashed clientipaddress context ip not hashed msclkid url parameter msclkid > properties msclkid > integrations\["microsoft capi"] msclkid microsoft click id for attribution phone validation phone numbers are validated before hashing the following are silently rejected common junk values n/a , na , undefined , null , none , unknown , test numbers with fewer than 7 digits all repeated digit numbers (e g , 1111111 ) custom data (track events) the custom event in each pair includes conversion properties microsoft field chord source (priority order) notes value properties revenue > properties total > properties price first numeric value found; order completed has no properties value field currency properties currency transactionid properties orderid / properties order id for deduplication searchterm properties query > properties search term eventcategory properties category eventlabel properties label pagetype (from event mapping table) e g , product , cart , purchase items see item attributes below item attributes for single product events (product viewed, product added), item data is extracted from top level properties microsoft field chord source id properties sku > properties product id > properties id quantity properties quantity price properties price name properties name for multi product events (checkout started, order completed, order placed), items come from the properties products array microsoft field chord source id products\[] sku > products\[] product id > products\[] id quantity products\[] quantity price products\[] price name products\[] name required fields for purchase events (order completed / order placed) to be accepted by microsoft, the following fields must be present event name and event time (populated automatically by chord cdp) properties currency properties value , properties revenue , or properties total (at least one) properties order id or properties orderid at least one user identifier properties email , properties phone , or msclkid (from url parameter) testing and validation after connecting the destination use microsoft ads event diagnostics (in the uet tags section of your dashboard) to confirm events are being received verify match rates — higher match rates indicate user identifiers (email, phone, msclkid) are being sent correctly confirm revenue values and order counts align with your expectations if discrepancies appear confirm msclkid is being captured in your page urls (microsoft appends this to ad click through urls) ensure required fields listed above are populated in your events check that your access token has not expired — regenerate in the microsoft ads dashboard if needed property mappings use custom property mappings if the default field resolution does not match your data model destination path description properties email email for enhanced conversions properties phone phone for enhanced conversions (e 164 format preferred) properties value primary conversion value properties revenue fallback conversion value (subtotal) properties currency currency code (e g , usd ) properties order id transaction id for deduplication properties products\[] sku product item ids properties products\[] price per item price properties products\[] quantity per item quantity properties products\[] name product display name updated 12 mar 2026