TL;DR
- Microsoft published its Conversions API documentation on Microsoft Learn with an ms.date of 4 August 2026 and a last update of 15 August 2026; Search Engine Land surfaced it on 18 August 2026.
- Events POST to https://capi.uet.microsoft.com/v1/{tagId}/events with a Bearer token, in batches of up to 1,000, with eventTime required inside the last 7 days.
- Every event needs at least one identifier from anonymousId, externalId, em, ph, msclkid, idfa or gaid; emails are SHA-256 hashed after a fixed normalisation and phones use E.164.
- The API is in beta and not yet available on every account, and Microsoft positions it alongside the UET tag, not as a replacement, with a shared eventId used to deduplicate.
Microsoft published full documentation for its Microsoft Advertising Conversions API on Microsoft Learn, with a live endpoint, two token routes, a 1,000-event batch cap and mandatory SHA-256 hashing of customer identifiers. The guide carries an ms.date of 4 August 2026 and a last-updated date of 15 August 2026, and Microsoft Learn is the source document; Search Engine Land surfaced it on 18 August 2026.
Two things to settle before anyone starts planning work. The API is in beta and not yet available on every account, so the first step is checking whether the option exists in your own account rather than scoping an integration. And Microsoft positions the Conversions API alongside the UET tag, not as a replacement for it. Nobody should be removing UET tags because of this.
What Microsoft shipped
Microsoft Advertising's Conversions API, documented on Microsoft Learn with a last-updated date of 15 August 2026, accepts server-to-server conversion events at https://capi.uet.microsoft.com/v1/{tagId}/events, authenticated with an Authorization: Bearer token.
There are two ways to get that token. The first is through the Microsoft Advertising interface, in the UET section, by going to the tagging setup, choosing the Conversions API option and copying the token. The second is programmatic, through the Campaign Management API at POST /CampaignManagement/v13/UetTagAuthKey/Query. The second route is the one that matters for anything automated, because a token copied by hand out of an interface is a token somebody has to remember to rotate.
Two event types are supported: pageLoad and custom. Every event carries an eventTime as a UNIX UTC timestamp, and that timestamp has to fall within the last 7 days. Events older than that are outside what the API accepts, which sets a hard ceiling on how long a backfill or a nightly CRM export can lag.
Identity: at least one identifier, hashed to Microsoft's exact recipe
Microsoft's Conversions API documentation requires every event to include a userData object carrying at least one identifier drawn from anonymousId, externalId, em, ph, msclkid, idfa or gaid. One is the floor, not the target.
Email hashing follows a specific normalisation sequence before the hash, and skipping a step produces a hash that will never match. Microsoft's steps are: trim whitespace, strip dots from the user portion of the address, remove the plus alias, lowercase the whole thing, then SHA-256 and encode as lowercase hexadecimal. Phone numbers have to be normalised to E.164 format first.
Analysis: this normalisation list is where server-side integrations usually fail silently. An address that reaches the CRM as First.Last+shop@example.com and one typed as firstlast@example.com are the same person and produce the same hash only if every step is applied in order. Miss the dot-stripping and the two hashes diverge, the events post successfully, the API returns no error, and the match rate is quietly poor. There is no failure signal to alert on, which is why the normalisation code deserves a unit test against Microsoft's own worked steps rather than a quick review.
The awkward case is a business that captures only a phone number, which describes a great many lead-generation advertisers. One identifier is enough to send an event, so a phone-only business is inside the requirement. What it cannot expect is the match quality of an advertiser sending msclkid alongside a hashed email, because a phone number normalised to E.164 can only match where Microsoft holds that number against a user. Sending fewer identifiers is allowed. It is not free.
Batching, and what happens when one event is malformed
Microsoft's Conversions API accepts up to 1,000 events per batch and, per the documentation published in August 2026, rejects the entire batch if any event fails validation, unless the request sets continueOnValidationError to true.
That default is a design decision worth respecting rather than switching off. All-or-nothing means a broken batch is loud: it fails, somebody notices, the bad event gets fixed. Setting continueOnValidationError to true makes the pipe forgiving and the failures invisible, so a field that silently stopped populating three weeks ago keeps costing conversions with nothing in the logs to catch the eye. If it is turned on, the rejected-event count has to be logged and alerted on, or the flag is just a way of hiding data loss.
Deduplication: the shared eventId is the load-bearing part
Microsoft requires the same eventId to be sent through both the UET tag and the Conversions API for the same conversion, so the two paths can be deduplicated into one recorded conversion.
The mechanism is simple and the consequence of getting it wrong is not. A conversion that fires client-side through UET and is also posted server-side through CAPI is one purchase seen twice. Without a shared key, the platform has no way to know that, and the account reports two. Inflated conversion counts feed straight into bidding, so a bid strategy optimising toward a doubled signal will overpay on exactly the segments where both paths succeed, which are usually the highest-intent users. The eventId is not a tidiness feature. It is what stops the measurement fix becoming a bidding fault.
The ID Sync pixel, and where it is mandatory
Microsoft's documentation requires a client-side ID Sync pixel fired to https://c.bing.com/c.gif with Red3 (in the form BACID_<CID>) and VID parameters for dynamic remarketing, and recommends it for measurement quality generally. The VID value has to match the anonymousId sent in Conversions API events.
This is the detail that catches teams who assume a server-side API removes browser dependencies. It does not remove them here. Dynamic remarketing on Microsoft Ads still needs a client-side call, and the identifier bridge between the browser and the server payload has to line up on both sides. A CAPI project that skips it will work for conversion reporting and quietly fail to support dynamic remarketing.
The specification at a glance
The table lists the constraints Microsoft published in the Conversions API guide dated 15 August 2026. Every value is from the documentation.
| Constraint | Value published by Microsoft |
|---|---|
| Endpoint | POST to https://capi.uet.microsoft.com/v1/{tagId}/events with a Bearer token |
| Event types | pageLoad and custom |
| Event age limit | eventTime must be a UNIX UTC timestamp within the last 7 days |
| Batch size | 1,000 events, all-or-nothing unless continueOnValidationError is true |
| Identifier handling | At least one of anonymousId, externalId, em, ph, msclkid, idfa, gaid; email SHA-256 as lowercase hex after normalisation, phone in E.164 |
Why server-side conversion APIs exist at all
Analysis rather than a claim from Microsoft's documentation: browser-based conversion tracking has been losing coverage for years for three separate reasons that stack. Safari's Intelligent Tracking Prevention caps the lifetime of script-written cookies, so a returning visitor can look like a new one. Ad and tracker blockers stop the tag executing at all for a slice of users, and that slice skews toward the technical and higher-income audiences many B2B advertisers are chasing. Consent frameworks mean a refused banner legitimately prevents the tag from firing.
A server-side API changes where the event comes from. Instead of the visitor's browser reporting the conversion, the advertiser's own system reports it, using data the advertiser already holds because the transaction happened there. It does not defeat consent and it is not supposed to: an event a customer refused consent for should not be sent. What it recovers is the signal lost to technical breakage rather than to a legitimate refusal.
The second thing it unlocks is conversions that never touch a browser. A lead that closes on a phone call three weeks after the click, a booking finalised over chat, an in-store purchase matched to a CRM record: none of those produce a page load, so no client-side tag can report them. A server-side pipe is the only way that outcome reaches the bidding system at all.
What this actually costs to implement
Analysis: this is engineering work, not a tag manager toggle. Somebody has to build a job that reads conversions out of the source system, normalises identifiers to Microsoft's exact specification, hashes them, batches them under 1,000, posts them with a token that is rotated rather than pasted, handles rejections, and carries an eventId that also reaches the UET tag on the client. That is a service with retry logic and monitoring, and it needs an owner after launch, because the failure mode is silence rather than an error page.
The alternative route is buying the plumbing. Microsoft names partner integrations already live: Segment (Twilio), Tealium, Stape.io, MetaRouter, Commanders Act, Freshpaint and Invoca, with Adobe Real-Time CDP and Switch Growth listed as coming soon. A team already running a customer data platform or a server-side tag container has most of the work done, and the remaining task is configuration plus verifying that the identifier normalisation the vendor performs matches what Microsoft specifies.
What Microsoft did not say
Microsoft's Conversions API documentation states that the API is in beta and not yet available on every account, and it does not give a general availability date. No timeline was published, so an advertiser who cannot see the option today has no stated date to plan against and has to check the account rather than wait for an announcement.
Microsoft also published no estimate of how much conversion signal an advertiser should expect to recover. Any percentage attached to this launch is somebody's guess, and the honest answer is that recovery depends entirely on how much of a given account's traffic was being lost to browser restrictions in the first place, which varies by device mix, browser mix and audience. Test against your own before and after, and do not budget against a number nobody published.
What this means for Thai marketers
Microsoft Ads is a small channel in Thailand rather than a primary one, and no market share figure appears in Microsoft's documentation, so nobody should be quoting one. Its practical appeal here has been cost: for Thai B2B and travel advertisers, Bing inventory tends to be cheaper than the equivalent Google auction, which makes it a useful secondary channel when the volume exists.
The part that fits Thailand well is offline and CRM event support. A very large share of Thai lead generation does not convert in the browser at all. The click lands, the conversation moves to LINE, and the deal closes on a phone call days later. A client-side tag never sees that outcome, so bidding on those accounts has been optimising toward form fills that may or may not have been real leads. A server-side pipe is what carries the actual closed lead back. The 7-day eventTime limit is the constraint to design around: a nightly or twice-weekly CRM export stays inside it comfortably, a monthly reconciliation does not.
On the build route, server-side GTM and Stape.io are already common in Thai agency stacks, and Stape.io is one of the named partner integrations, so the realistic entry point for most Thai teams is the container they already run rather than a bespoke service. That still leaves the identifier work: Thai phone numbers stored as 08x or 06x need converting to E.164 with the +66 country code and the leading zero dropped, and a CRM full of locally formatted numbers is the most likely reason a first integration matches badly.
Questions about the Microsoft Advertising Conversions API
Can I use it right now?
Maybe, because Microsoft states the Conversions API is in beta and not yet available on every account, so the only reliable check is looking for the option in the UET section of your own Microsoft Advertising account. Microsoft published no general availability date, so there is no announced timeline to wait for.
Do I remove my UET tag if I use the Conversions API?
No. Microsoft positions the Conversions API alongside UET rather than as a replacement, and it requires a shared eventId across both paths so the same conversion is deduplicated into one, which only works if both are running.
Is it available in Thailand?
Microsoft's documentation does not address Thailand or any country-level availability, so the source did not say. What it did say is that availability is per account during the beta, which means checking your own account is the answer rather than checking a country list.
How much conversion data will I get back?
Microsoft published no figure and no expected recovery rate, so any percentage you see quoted is invented. The amount depends on how much of your traffic was already being lost to browser restrictions and how many of your conversions happen offline, both of which vary too much between accounts for a general number to mean anything.
Can my tag manager do this without developers?
Partly. Microsoft names Segment (Twilio), Tealium, Stape.io, MetaRouter, Commanders Act, Freshpaint and Invoca as live partner integrations, with Adobe Real-Time CDP and Switch Growth coming soon, so a team already running one of those has a configuration job rather than a build. A team with no server-side infrastructure is looking at real engineering work, because identifier normalisation, hashing, batching and eventId consistency all have to be correct.
If you are weighing whether server-side conversion tracking is worth the build in your stack, the honest first step is measuring what you are currently losing. Our analytics and measurement team can audit where your conversion signal breaks, and our paid search team can tell you whether the recovered signal would actually change how your campaigns bid.
