Microsoft Ads Conversions API in Server-Side GTM (2026 Guide)

The Microsoft Ads Conversions API documentation runs to about forty screens, and 90% of it only covers edge cases. Here are the six fields that actually decide whether your conversions come through, plus the trap everyone is about to fall into on the server side. Since August 18, 2026, Microsoft Advertising has finally shipped the full docs for its Conversions API (CAPI): event schemas, authentication, error handling. It is the last major paid channel to go server-to-server, and for now the only content out there is vendor product pages. This guide walks the full path in server-side GTM, and it settles the architecture mistake that your sGTM instinct pushes you to make.

One useful warning first: Microsoft’s CAPI is in invite-only beta, provisioned account by account through your account manager. The docs are still moving. Treat this guide as a solid baseline, not gospel, and double-check your field behavior at the moment you wire it up.

What Microsoft shipped on August 18, 2026

In practice, Microsoft is opening the same model Meta and LinkedIn shipped before it: a server-to-server endpoint that receives your conversion events alongside the browser tag. The new part is the official documentation. We now know the exact payload schema, the token authentication scheme, the return codes, and the batching rules.

What stays in beta: access itself (you have to be provisioned) and a handful of fields whose behavior may shift. What is already stable and usable: the endpoint, the event structure, deduplication with UET, and attribution handling through msclkid. That is more than enough to build a clean setup right now if your account is eligible.

Why bother this early? Because Microsoft Advertising is the B2B channel on the rise, in particular with ad placements inside Copilot’s generative answers. And that is exactly where browser-only measurement is weakest. If you are trying to get a handle on that assistant-driven traffic, the topic sits right next to tracking AI traffic in GA4.

CAPI does not replace UET, it doubles it

First instinct to correct: the Conversions API is not a replacement for the UET tag, it is a server-side complement. The architecture Microsoft recommends, and the only one that holds up, keeps the UET tag client-side in the browser and adds CAPI server-side from your sGTM container. Both describe the same event, Microsoft receives them twice, then reconciles them.

The principle is identical to what you already know if you have wired up Meta CAPI and its deduplication or LinkedIn Conversions API. A browser signal for coverage and remarketing, a server signal for resilience against blockers and consent refusals. Remove either one and the whole thing degrades.

The prerequisites

Three things before you write a single line of configuration. One, a provisioned account for the CAPI beta (without it the endpoint answers 401). Two, your UET tag ID, the same numeric identifier already deployed in your web container. Three, an authorization token.

You generate the token in the Microsoft Advertising UI: UET, then Set up tagging, then Use Conversions API, then Copy Token. For those who automate, there is also the POST /CampaignManagement/v13/UetTagAuthKey/Query call. This token goes into the Authorization: Bearer <ApiToken> header of every request. Treat it as a secret: it lives server-side, never in the browser.

And of course you need a real hosted server-side container. If you have not made the jump yet, start with the guide to migrating to server-side GTM.

The sGTM setup

Two routes. The fastest: the Stape “Microsoft Ads UET Conversion API” template, which wraps the call and lets you map fields inside the GTM UI. The most controlled: a direct HTTP tag that sends the payload by hand.

The endpoint is:

POST https://capi.uet.microsoft.com/v1/{tagId}/events
Authorization: Bearer <ApiToken>
Content-Type: application/json

The payload has three levels. At the request level you have data (the event array), continueOnValidationError, and dataProvider. At the event level, the fields that matter: eventType, eventTime, eventId, eventName, eventSourceUrl, adStorageConsent. There are two eventType values, pageLoad and custom, linked together by a pageLoadId. Then come userData (matching data) and customData (monetary value and transaction details).

On batching, Microsoft accepts up to 1,000 events per request, but prefers real time. The responses to know: 200 when everything goes through, 400 on a validation error, 401 when the token or the provisioning is the problem.

Deduplication, the setting you cannot get wrong

Same trap as on every CAPI: if dedup is misconfigured, Microsoft either double-counts your conversions or drops part of them. The rule is simple. The browser UET tag and the server CAPI call must send the same eventId, the same eventName, and point to the same tagId. Meet those three conditions and Microsoft understands it is a single conversion and merges the sources.

In practice, generate the eventId once on the browser side (a UUID set at the moment of the event, for example), push it into the dataLayer, then pass it to the server container so it replays the exact same value. The classic mistake: letting the server generate its own identifier. Two different IDs, and the merge never happens.

Attribution: capturing and replaying the msclkid

The msclkid is to Microsoft what the gclid is to Google: the click identifier that ties the conversion to the campaign. Its retention window is 90 days. Your job is to capture it on arrival (it comes in as a URL parameter), store it, then replay it in the userData of every CAPI event.

Without msclkid, Microsoft falls back on probabilistic matching from the other signals (em for the hashed email, ph for the phone, clientIpAddress, clientUserAgent). It works, but attribution is noticeably weaker. Replaying the msclkid is the move that pays the most for the least effort.

The trap: ID Sync stays client-side

Here is the part nobody has written yet, and the mistake your sGTM instinct will lead you into. On the server side, the reflex is to push everything to the server. With Microsoft, that is a mistake. ID Sync has to stay in the browser.

ID Sync is the client call to c.bing.com/c.gif that sets and syncs the advertising identifiers: Red3 equals BACID_<CID>, VID maps to the anonymousId, UID is optional. That call feeds Microsoft’s dynamic remarketing. Move everything server-side and kill the browser ID Sync, and you lose the ability to retarget while your matching degrades.

The easiest thing to miss, and the most expensive: the VID from ID Sync must match the anonymousId you send in CAPI. If the two values diverge, Microsoft will not tie the server user back to their browser profile, and you stack both problems, broken remarketing and truncated matching. Remember the rule: UET and ID Sync client-side, CAPI server-side, and one shared anonymousId across both.

Consent and Consent Mode v2

Every CAPI event carries an adStorageConsent field that reflects the user’s advertising consent state. It maps directly to your Consent Mode implementation. If you have already wired consent signals for Google, the logic carries over: the granted or denied state of ad storage should flow into adStorageConsent. For the full signal mechanics, see the Consent Mode v2 for GA4 and Google Ads guide.

Do not hard-code that state. An adStorageConsent permanently set to “granted” exposes you on the regulatory side and skews Microsoft’s read. Wire it to your CMP.

Validation checklist

Before you call the setup done, check in order: the account is provisioned and the endpoint returns 200; the token goes out as a server header and never in the browser; eventId, eventName, and tagId are identical between UET and CAPI; the msclkid is captured and replayed; ID Sync still runs client-side; the VID from ID Sync equals the anonymousId sent in CAPI; adStorageConsent is wired to your CMP.

Should you jump in now?

Microsoft’s CAPI is still young and moving, but the skeleton is there and the field is empty. A clean setup today, meaning UET client plus CAPI server, dedup by eventId, msclkid replayed, and ID Sync left on the browser, puts you ahead on a channel most of your competitors still measure with the browser alone. If your account is eligible, now is the time to wire it.