Microsoft Advertising has published full documentation for a server-side Conversions API (CAPI) that sends conversion and customer interaction data directly from an advertiser's systems to Microsoft, running the same event model as the browser-based Universal Event Tracking (UET) tag. The reference material carries a last-updated date of August 4, 2026, and describes the product as a pilot that Microsoft provisions per account. Advertisers cannot switch it on themselves.

In Shorts

Microsoft built a new way for advertisers to send their sales and lead data to Bing Ads straight from their own computers, instead of relying on a tracking script inside the shopper's web browser. This matters because browsers like Safari and ad blockers increasingly stop that script from working, which means advertisers lose track of sales they actually paid for. The catch is that you cannot turn the new tool on by yourself yet. Microsoft has to enable it on your account, so for now most advertisers only have the instructions and not the access.

What Microsoft documented

The Conversions API is described in Microsoft's developer documentation as the company's server-side solution for sending conversion and customer interaction data directly from an advertiser's systems. According to Microsoft, advertisers can use CAPI to send website events, CRM events, offline sales transactions, and mobile events through a single setup, supporting multiple measurement scenarios with one connection.

The stated reasons for adopting it are set out in the documentation: improving conversion measurement accuracy, sending online, offline, CRM, and app events through one setup, increasing attribution coverage, supporting audience creation for dynamic remarketing, reducing reliance on browser-only tracking solutions, and, in Microsoft's phrasing, future-proofing measurement investments as privacy requirements continue to evolve.

The mechanism is a direct server-to-server call. Rather than the visitor's browser posting to Microsoft, the advertiser's backend, or a server-side tag manager container, sends an HTTP POST request to the endpoint at capi.uet.microsoft.com, using the path format /v1/{tagId}/events. Authorization is a Bearer token tied to the specific UET tag that owns the relevant conversion goals. The endpoint returns an HTTP 200 status code on success, or an HTTP 400 or 401 code with error details.

This is not framed as a replacement for the browser tag. Microsoft recommends using CAPI with UET whenever possible. The documentation states that UET captures browser-based activity and page context, while CAPI provides a server-side path for sending additional events and details that occur after UET fires. The same guide also treats CAPI as an alternative when JavaScript cannot be used.

Why browser-only measurement has become fragile

The reason a server path matters now is that the browser tag has grown unreliable. UET is a client-side script. It loads in the visitor's browser, reads the Microsoft Click ID, writes cookies, and sends page loads and conversions to Microsoft from the device. If the script never loads, or the network call never completes, Microsoft never records the visit.

Safari is the sharpest case. In Safari 27, which is in beta and ships with iOS 27 and macOS 27, WebKit's tracking protection can block the connection to Microsoft's ad servers at the network layer, by domain and by IP range, before any data leaves the device. A first-party proxy that only changes where the script loads from does not help, because the browser still has to reach Microsoft's servers, and those addresses are what the protection can cut. PPC Land reported in July 2026 that the Bing UET endpoint and the LinkedIn Insight Tag were both confirmed on the exposed list in the Safari 27 analysis, alongside filtering of the si and twclid parameters that affects YouTube and X campaigns.

Ad blockers apply the same treatment, dropping the UET script or the request to Microsoft's servers through EasyList-style filters, while strict tracking protection modes in Firefox and Edge do the same. The pattern is broader than any single browser: ad blockers have begun naming server-side tagging subdomains directly, so even first-party routing no longer guarantees delivery.

Cookies present a slower version of the same problem. Safari's Intelligent Tracking Prevention caps many JavaScript-set cookies at seven days, shrinking remarketing lists and stripping the click identifier that a conversion on a return visit would need. Safari's Link Tracking Protection can also remove the Microsoft Click ID from links opened in Private Browsing and from Mail or Messages, the same way it strips the identifiers Google and Meta rely on. When the click ID never lands on the page, the browser tag has nothing to attribute even when the network call itself succeeds.

The consequence for spend is direct. Campaigns keep running while the conversion signal that should train automated bidding arrives late or not at all, which can make a channel look weaker than it is when the real problem sits in the measurement layer rather than in the media.

The two website event types

For websites, the documentation defines two event types that work together.

Page load events are sent once per page view, including single-page application route changes. They carry page context: the page URL in the eventSourceUrl field, the referrer URL, the page title, keywords, and a pageLoadId formatted as a version 4 universally unique identifier. Destination-based conversion goals and page-context matching depend on these events. Sending only purchases and skipping page loads is described as the most common incomplete setup.

Custom events capture specific user actions such as checkout completion, form submission, cart activity, search results, product views, or purchase confirmation. Richer fields live here, including value, currency, transaction ID, and product identifiers. When a custom event corresponds to a page load, it should reuse the same pageLoadId so Microsoft can associate the action with the page context.

Two constraints stand out. Conversion goals have to exist in Microsoft Advertising before events are sent, matched to the same UET tag and the eventName being posted. If no goal is tied to that tag and matching the event action, Microsoft will accept the events with a 200 response and no conversion will appear in the interface. The second constraint concerns revenue: it cannot ride on a page load event. If a destination URL goal needs variable revenue, Microsoft's documented answer is to send a second custom event carrying only the revenue value and the matching pageLoadId.

Timing is enforced. The eventTime field is a UNIX timestamp in seconds, and Microsoft rejects timestamps older than seven days. Events can be uploaded individually or in batches, with real-time delivery preferred and a maximum of 1,000 events per batch upload.

Access is provisioned, not self-service

The detail that separates this launch from a general availability release is enrollment. The documentation is public and complete, but access is a pilot that Microsoft grants per account. The flag lives on the customer account that owns the UET tag, identified by its customer ID, and the route in is to ask a Microsoft account manager or Microsoft Advertising support to enroll that customer ID.

Once an account is enrolled, the token appears under the UET tag in the Microsoft Advertising interface. The documented steps are to edit the tag, move through the tagging setup, select Use Conversions API, and copy the token. A Campaign Management API call, UetTagAuthKey/Query, returns the same kind of key: it accepts a UET tag ID and returns the authorization token, creating a new one only when the caller owns the tag. Callers with access to a shared tag can retrieve an existing token but cannot generate a new one.

Before enrollment, the Use Conversions API option is simply absent from the screen. There is a structural trap for agencies here: a manager account can look fully configured while the client's own customer ID has no CAPI access, because the flag sits on the account that owns the tag.

The identity layer that does not move server-side

Moving the event payload to the server does not move identity matching with it. Microsoft's documentation still calls for a client-side ID Sync pixel to map an advertiser's visitor identifiers to Microsoft identifiers, and it specifies that this must be a client-side pixel rather than a server-side call, so Microsoft can read browser context at the moment of the sync. The pixel is sent to https://c.bing.com/c.gif and, according to the documentation, should fire on as many pages as practical and at least once per session.

The field names are precise. Red3 is required and formatted as BACID_ followed by the Microsoft customer ID, which is not the UET tag ID: a single customer account can hold several UET tags. VID, also required, is the anonymous guest identifier, preferably a version 1 UUID, and it must match the anonymousId sent in the CAPI events. If those two values drift apart, Microsoft cannot join the server event to the sync. UID is an optional anonymized signed-in user ID that lines up with the externalId field on the CAPI side.

Microsoft describes ID Sync as required for audience creation, remarketing, and dynamic remarketing, and as strongly recommended for conversion measurement quality, particularly when the click identifier or hashed identifiers may be incomplete. The documentation is explicit that raw email addresses, raw phone numbers, and real user IDs should not be sent through the sync.

The pixel is itself a browser call, which means Safari and ad blockers can cut the request to c.bing.com the same way they cut the request to Microsoft's ad servers. That is the reason the documentation leans on identifiers the advertiser controls on the server event.

Click ID, hashed identifiers, and matching

The Microsoft Click ID, msclkid, remains central to attribution. With auto-tagging enabled, Microsoft appends it to the landing page URL after an ad click. The UET JavaScript tag used to capture that value automatically; on CAPI, capturing and storing it becomes the advertiser's responsibility.

Microsoft's guidance is specific. The most recent click ID should be stored per user in a first-party cookie, local storage, or a server-side store, overwritten when a newer value is captured, retained for a suggested period of 90 days, and included in later events for that user. The format is a UUID. The documentation states that visitor ID alone should not be relied on for attribution when the click ID is available. Because Safari's Link Tracking Protection can remove the click ID before the page runs, a server-side container cannot recover a query parameter that never reached the site, which is where the hashed identifiers become the fallback.

To improve matching when cookies and click IDs are missing, the schema carries hashed email in the em field and hashed phone in the ph field, each a SHA-256 hash of a normalized value formatted as a lowercase hexadecimal string. Microsoft's normalization rules for email require trimming whitespace, removing dots from the user portion, removing any plus-alias, and converting to lowercase before hashing; phone numbers are normalized to E.164 format with country code before hashing. Microsoft refers to this hashed-identifier matching as enhanced conversions, carried on the same CAPI payload. Every event must include a userData object with at least one supported identifier, drawn from the anonymous ID, external ID, hashed email, hashed phone, click ID, Apple's advertising identifier, or the Google advertising ID.

The API supports explicit consent signals through the adStorageConsent field, using G for granted and D for denied. Events marked denied are not used for any advertising purpose, including attribution and retargeting. If the field is omitted, Microsoft treats consent as granted by default. For advertisers operating under European rules, that default places the burden on the implementation to pass the correct signal, the same discipline that governs consent mode on the Google side, where a banner that appears to work but fails to transmit signals has produced documented conversion collapses. The requirement applies wherever consent must be captured before advertising storage, which for the EEA and the UK has been enforced against non-compliant accounts.

Deduplication addresses the double-counting risk that arises when the same conversion is sent by both UET and CAPI. Microsoft's method is a shared, stable eventId passed on both systems for the same conversion, using the same UET tag ID and a compatible eventName so the platform recognizes the duplicate and counts it once. The documentation notes that stable event identifiers also prevent retries from creating duplicate conversions.

Batch behavior interacts with validation in a way worth planning for. By default, if any single event in a batch fails validation, the API returns HTTP 400 and processes none of the events in that batch. Setting continueOnValidationError to true changes this: the API returns HTTP 200 when at least one event is valid, skips the invalid events, and reports them separately. The documentation also distinguishes validation errors, which invalidate an event, from validation warnings, which apply to optional fields whose values cannot be accepted; a warning causes Microsoft to remove the affected field and process the event without it, still returning a 200. A 200 response, in other words, is not proof that every field was accepted.

Where the events belong in a tag manager

Microsoft's documentation lists a tag manager or server-side tag manager as a valid sending path, alongside a direct API build and partner integrations. The architecture mirrors the pattern already used for other platforms' server tags: the browser talks to a first-party domain the advertiser controls, and the server container issues the POST to Microsoft, so the blocked browser-to-Microsoft call is never made. The split is that conversion events belong in the server container while the ID Sync pixel stays in the web container, because it has to run client-side. This is the same auto-tagging plumbing that appends the click ID at the landing page, now paired with a server path for the event body.

Microsoft's published list of current partner integrations names Commanders Act, Freshpaint, Invoca, MetaRouter, Segment, Stape.io, and Tealium as having available connectors, with Adobe Real-Time CDP and Switch Growth marked as coming soon. Each partner may handle event mapping and formatting, but the documentation is clear that the advertiser still needs the correct account, UET tag, token, conversion goals, consent approach, and identifiers in place.

Where this sits in a wider industry shift

Server-side conversion APIs have moved from an advanced technique to a default expectation across the major platforms, and Microsoft's arrival closes an obvious gap in that lineup. The pattern of moving conversion measurement off the browser and onto a server the advertiser controls is now shared by Google, Meta, and TikTok, and increasingly by connected TV platforms.

The evidence base for the approach has been building for more than a year. A 26-page IAB guide released on October 30, 2025 reported that two-thirds of advertisers saw improved return on ad spend after implementing Conversion APIs, based on survey data collected between July 22 and August 19, 2025, with three-quarters of advertisers indicating a willingness to reallocate spending based on conversion insights. The same body of research found that 67 percent of Conversion API implementations run alongside pixels rather than replacing them, which matches Microsoft's own recommendation to keep the UET tag running wherever it loads.

Individual platforms have quantified the gains for their own systems. Meta's one-click Conversions API, which went live in April 2026, was accompanied by a Meta figure that advertisers with a Conversions API setup for web events saw an average 17.8 percent lower cost per result than those without one. That release also illustrated the direction Microsoft has not yet taken: Meta reduced its setup to a no-code, one-click path precisely because technical complexity had become a barrier to adoption. The industry has been standardizing that complexity away, from the IAB Tech Lab's ECAPI 1.0 specification, finalized on May 3, 2026 as a shared standard for conversion APIs, to platform-level automation. Microsoft's implementation, by contrast, requires a manual enrollment request and hand-mapped payloads, which places it earlier on that curve.

There is also a Microsoft-specific precedent. In April 2024, Microsoft Advertising began auto-enabling the Microsoft Click ID on eligible accounts to bridge conversion gaps caused by browser privacy settings, positioning the identifier as a way to track conversions when the standard Microsoft cookie could not be used. The Conversions API extends that same logic to the transport layer: where auto-tagging preserved the click ID against cookie loss, the server path preserves the entire event against the browser-level blocking that now reaches the network call itself.

What remains unresolved

Two open questions sit at the center of the pilot. The first is timeline. Microsoft's documentation does not state when, or whether, the Conversions API will move from per-account provisioning to general availability, nor how long enrollment requests take to process. The second is the residual gap that server-side delivery does not close: if Safari or an ad blocker cuts the ID Sync pixel, Microsoft cannot join a visitor's identifiers to its own on those sessions, so remarketing lists miss that traffic even though the conversion itself still lands from the server. The documentation's answer is to lean on the click ID, the anonymous ID, and hashed email or phone on the server event, but it does not claim those identifiers fully replace what the pixel would have matched.

For advertisers measuring Microsoft campaigns with a browser-only UET setup, the documentation makes the shape of the fix clear while the access to implement it remains gated. The instructions are complete. The switch is not yet on the screen.

Timeline

  • April 2024: Microsoft Advertising begins auto-enabling the Microsoft Click ID on eligible accounts to bridge browser-driven conversion gaps
  • September 4, 2025: Safari 26 ships with iOS 26 and macOS 26, activating Advanced Fingerprinting Protection by default for all browsing sessions
  • October 30, 2025: The IAB releases a 26-page guide on standardized Conversion APIs, reporting two-thirds of advertisers improved ROAS after implementation
  • April 2026: Meta launches its one-click Conversions API, citing an average 17.8 percent lower cost per result for advertisers using CAPI for web events
  • May 3, 2026: The IAB Tech Lab finalizes the ECAPI 1.0 specification as a shared conversion-API standard
  • July 2026: PPC Land reports the Safari 27 analysis confirming the Bing UET endpoint and LinkedIn Insight Tag among the blocked and restricted trackers
  • August 4, 2026: Microsoft's Conversions API documentation carries this last-updated date, describing the API in full as a per-account pilot

Summary

Who: Microsoft Advertising, through its developer documentation for the Conversions API, aimed at advertisers, agencies, and analytics engineers measuring Microsoft Ads campaigns.

What: A server-side Conversions API that sends website, CRM, offline, and mobile events directly from an advertiser's systems to Microsoft using the same event model as the UET tag, documented in full but released as a per-account pilot that advertisers cannot self-activate.

When: The documentation carries a last-updated date of August 4, 2026, and describes the product as a pilot Microsoft provisions on request.

Where: Events post to the endpoint at capi.uet.microsoft.com, with the flag enabled on the customer account that owns the UET tag; the ID Sync pixel fires client-side to c.bing.com.

Why: Browser-based UET measurement has become unreliable as Safari 27 and ad blockers cut the tag's network calls and cookie limits expire the identities remarketing depends on, so a server path the advertiser controls preserves the conversion signal that automated bidding needs.