Microsoft Ads API Now Locks the Gate With Two Keys, Not One

What actually changed inside the Microsoft Ads API#

A fox does not force a locked gate. It reads the latch, catches the scent of what is new, and waits for the right moment before it pushes through. That patient, practical posture is exactly what agencies and ad-tech teams need this week, because the Microsoft Ads API has had its latch changed twice: quietly in May, and unmissably on 26 August.

Microsoft first posted the change on 27 May 2026, in a short, sober note on the Bing Ads API Blog inside the Microsoft Community Hub: a new dual ID requirement for account linking APIs. Reading it in May, the update looked like tidy housekeeping, the sort of policy note that sits quietly for months without touching a single running integration. Enforcement began on 26 August 2026, and a quiet policy post turned into the most disruptive line of code most Microsoft Ads API integrations will meet this quarter.

The mechanics are easy to state and awkward to retrofit. Manager account linking, built on a CID (a customer ID), used to accept a single Manager Account Number on its own. It now needs that number paired with a numeric Manager Account ID before Microsoft's Customer Management Service will even consider the request. Account linking, built on an XID, used to accept a lone Manager Account Number too. It now needs that same Manager Account Number paired with the target Account Number of the advertiser account being linked, the dual ID account linking pattern that gives this whole change its name.

Two boxes to tick, not one#

Microsoft frames the change bluntly. Previously, the company says, linking could be initiated using a single identifier, which increased exposure to brute-force attempts, a line that reads less like marketing copy and more like an incident report someone finally acted on. The fix is not cleverer fraud detection working invisibly behind the scenes, it is a second, mandatory field standing at the gate itself, and every account linking API call now has to carry it.

Read that line the way a fox reads a rising tide along the shoreline: nothing looks urgent in week one, and everything is urgent by week four. Treat 26 August as a soft launch and your Microsoft Ads API integration risks being quietly starved of new links by the time the tide reaches its highest mark on 22 September.

Why a brute-force problem becomes your problem#

Every account linking API eventually asks for the same thing twice: proof you actually control both ends of the request. Account hijacking is not an abstract worry for a platform that used to let one customer request control of another customer's advertiser account by number alone. Microsoft's own ClientLink documentation already defines what happens when the numbers do not line up: a LinkPairMismatch error fires when an account ID does not match its target, and a ClientLinkFieldInvalid error fires when a required field is missing outright. Both error codes existed long before 26 August. What changed is which fields are required before either one can fire at all.

The underlying service operation, AddClientLinks, has always accepted a ClientEntityId or ClientEntityNumber alongside a ManagingCustomerId or ManagingCustomerNumber, laid out in full in Microsoft's Customer Management Service reference. The dual ID account linking rule does not bolt a new field onto the schema. It removes the option to submit only half of what the schema always allowed, closing a door that had stood conveniently ajar since the service first shipped.

Picture the integration that only ever sent a Manager Account Number, the single key that used to work every time. From 26 August it slides that same key into a lock built for two, turns it, and nothing moves. The request is not queued, delayed or flagged for later review. It is rejected outright, the way a fox turned back from a den mouth too narrow for two does not squeeze through by pushing harder.

The wider pattern: platforms are hardening the front door#

Microsoft is not acting alone, and that matters more than the specific field names. Google tightened its own Ads API authentication twice in 2026 before Microsoft's dual ID account linking rule ever took effect: a mandatory multi-factor step for new OAuth 2.0 refresh tokens from 21 April 2026, confirmed in an agency compliance guide to the change, then a harder passkey requirement layered on top from 5 August 2026 for anyone generating a fresh token through the standard user-authentication workflow.

“These important security updates will start rolling out from August 5, 2026, and will be enabled for all users over the next few weeks,” Google's own Ads API developer blog states, framing the change as protection against the same credential-stuffing and brute-force pressure Microsoft cites for its dual ID account linking rule.

The shape repeats across both platforms. A single credential that used to be sufficient stops being sufficient. Existing sessions are grandfathered so nothing breaks retroactively. New requests carry the extra weight going forward. Neither company frames its change as a response to the other, and neither needs to: every large ad platform now fields enough account-takeover attempts against its own Microsoft Ads API or Google Ads API that a single shared identifier looks less like convenience and more like a side door left unlocked for a decade.

For a paid-search team running budgets across both platforms, the lesson generalises past this one field. Whatever number your tooling treats as a master key this year is the number a platform is most likely to demand a second proof for next year. Auditing single-identifier assumptions across the Microsoft Ads API and every other platform you touch is cheaper done once, on your own schedule, than done five times, on five different platforms' schedules, the same discipline behind folkfox's audit of Microsoft's other August changes.

The practical fix: five checks before the window closes#

None of this needs a rebuild. It needs an audit of every place your codebase still assembles a Microsoft Ads API linking request from one field where the schema always had room for two.

The second step is the one teams skip, and it is the one that causes the quiet failures later. A tool built only for agency-side manager linking never touches an XID at all, and a tool built for direct account linking never touches a CID. Fixing the wrong half of the pair is a fast way to ship a patch that still fails in production on 23 September.

Budget a genuinely small amount of engineering time for this, a day at most for most integrations, because the fields already exist inside the Microsoft Ads API schema. You are not building new plumbing. You are filling in a pipe that was already there, half-connected, since the service first shipped, and if you maintain a Microsoft Advertising SDK wrapper rather than calling the raw Microsoft Ads API directly, check the wrapper's own changelog too, because the dual ID account linking fields need to reach your code through it.

Proving you are actually compliant, not just hopeful#

Compliance here is provable, not a matter of hope. Microsoft's own API FAQ and its Getting Started guide both point back to the same Customer Management Service documentation that defines these fields, so there is no separate dual-ID endpoint to test against. You test the same AddClientLinks call you always tested through the Microsoft Ads API, now with both fields populated.

Watch three things after you ship the fix. First, whether any linking call still returns ClientLinkFieldInvalid, which almost always means a code path you missed rather than a genuinely new bug. Second, whether pending links from before 26 August continue resolving normally, since Microsoft's notice states plainly they are untouched by the change, a distinction its Account Hierarchy and User Permissions guide helps make sense of for larger agencies. Third, whether your own release-note habit catches the next quiet policy post before enforcement, not after it, so this fortnight does not repeat itself in October.

The teams that will feel nothing on 22 September are the ones treating 26 August as the deadline it always was, not the ones waiting for a second announcement that Microsoft has already said is not coming. There is no soft second warning built into this rollout, only a widening enforcement window that closes the same door a little further shut with each passing week. This lands the same week Google reshaped how it bills missed calls on Local Services Ads, a reminder that August 2026 has been a month of platforms quietly rewriting the fine print across paid search.

This is exactly the kind of quiet-breaking change folkfox's PPC team audits for weekly, tied to the same reporting rigour covered in our recent look at Microsoft's bidding changes and the Google Ads API's own August update. A single unfixed call site is a small thing right up until the day the Microsoft Ads API stops accepting it, and that day, for the last integrations still carrying one identifier, is already here.

Frequently asked questions#