Release history

This release closes the V1 cycle and consolidates the foundation for the next product bricks. Three structural workstreams ran in parallel: (1) the admin UI was rebuilt around a central menu grouped by use case rather than by technology, with contextual links that follow an AdOps' actual workflow; (2) the MCP server moved to a parent/child architecture that takes the public catalogue from 270 tools down to 51 coherent dispatchers; (3) long-running operations (inventory blueprint generation, audit CSV export, image optimization) were offloaded to an independent worker service to keep the main backend lean.

The v2.0 bump reflects the scope of the rework rather than a single headline feature — every day-to-day action becomes more direct. Audit pages now show an honest "endpoint under construction" panel where data is not yet wired, rather than fabricated numbers: we'd rather be upfront than fake a demo. Practical consequence of the cleanup: some legacy URLs and endpoints are gone — see the compatibility note at the bottom of this release.

Multi-tenant ad networks and agencies told us loud and clear: they need to audit their GAM network against recognized standards (ISO 27001, IAB, NIST CSF) without manually stitching together dozens of requests. This release introduces an audit Skill that AI agents can run autonomously, plus a complete GAM administration layer (teams, sites, applications, labels). In parallel, the pricing assistant analyzes performance history to suggest optimal floor prices — with a strict guarantee: no tenant data is ever stored, everything is computed live.

Keeping the audit 100% MCP/CLI without a dashboard interface is deliberate. A compliance audit is first and foremost a checklist run by an intelligent agent, not a dashboard to scroll through. The resulting markdown report can be emailed, versioned in Git, and printed on a single A4 page when needed for a steering committee.

Publishers and ad networks selling programmatically needed to structure their commercial offer as a real catalogue: formats, floor prices, targeted audiences, booking conditions. This release introduces that business layer end-to-end — backend modeling, REST API, MCP tools and a complete dashboard interface. In parallel, native support for programmatic deals (PMP via REST, PG/PD via SOAP) makes it possible to orchestrate the negotiation and deployment of direct deals with buyers.

The ADCP (AdContext Protocol) bridge is probably the most strategic piece of this release. It lays the groundwork for an AI buyer agent — on the advertiser or agency side — to browse the publisher's product catalogue, then negotiate and deploy a deal without human friction. That's the missing layer between ad-tech infrastructure and truly end-to-end AI automation.

The MCP server was long the first entry point for AI agents. The CLI, on the other hand, grew in parallel to cover scriptable workflows: cron jobs, CI/CD integrations, teams that simply prefer a terminal. But the two surfaces had taken slightly different paths. This release commits to unifying them: every MCP operation has its mirror CLI command, every CLI command has its matching MCP tool. The parity matrix is now verified automatically on every build.

This release was also the occasion to refactor three backend services into more modular layers (billing reports, line item creation, inventory archiving). Invisible work for users, but it significantly accelerates the delivery of upcoming features. The public open-source repo is automatically synced on every internal push.

Publishers running hard in programmatic wanted to simulate the impact of a new campaign on already-serving line items — the so-called mutual contention. This release introduces get_prospective_delivery_forecast in multi-LI mode, plus forecast splits (by day, device, geo) and real traffic data ingestion. In parallel, we ran two live audits on a production account: the first wave surfaced four bugs invisible in test environments, the second another four. All fixed, all covered by regression tests.

The phase-11 quality audit (38 systematic fixes against the official WSDL schema) starts from a simple observation: it's better to invest in call rigor than in error-recovery layers. When you call GAM with exactly the right typed parameters, bugs disappear at the root rather than being caught at runtime.

Before every major product expansion, we take the time to audit the critical layers in depth — authentication, billing, campaign pipeline, reporting, frontend, MCP server. This release consolidates those foundations along six axes: hardened security at the OAuth protocol level, fully idempotent credit refunds, pipeline with progress checkpoints and incident recovery, and 9 UX micro-regressions fixed in the interface. It's the final step before the arrival of the Product Catalogue, Programmatic Deals and the AI audit suite.

This release doesn't ship a spectacular feature — that's the point. It cleanly closes the debt accumulated over eighteen months of fast delivery, so that the next major features rest on a platform whose every layer has been inspected line by line. The comfort of building fast comes from the rigor of having built well before.

A functional audit of reporting revealed inconsistencies between the displayed billing (FAQ, CLI) and the backend reality. In parallel, analysis of the GAM SOAP schema showed that native tracking fields (thirdPartyImpressionTrackingUrls, thirdPartyClickTrackingUrl, VAST trackingUrls) weren't being leveraged — we were injecting everything into the HTML. v1.8 corrects both axes and adds a complete audit/QA layer for tracking and archiving.

This is the first release where an AI agent can autonomously diagnose a tracking issue (missing macros, absent cachebuster, undetected vendor), fix it via update_creative, and re-verify — all in a single conversation. The pre-archive check prevents irreversible mistakes.

The question kept coming back in beta feedback: "How do I consolidate my GAM performance without leaving the interface?" The Reporting Hub answers that directly. In parallel, we tackled a technical debt around pagination — some GAM networks exceed 500 line items, and list tools were returning truncated results without warning. The fail_fast parameter on batch operations addresses a real need from teams that want partial deployments without having to roll back everything.

It's also the release where OrbiAds CLI v1.0 ships officially. Two years building MCP infrastructure, and ultimately the first concrete feedback showed us that part of our users just wanted a terminal and a cron job.

Moving the MCP from prototype to production was the turning point of this cycle. For months, the SOAP infrastructure was there but the AI entry point remained experimental. Putting the MCP server in production on orbiads.com/mcp, with clean OAuth2 authentication and no API key to manage, changed the nature of the product. Inventory Explorer was born from a simple observation: before deploying anything, AdOps teams need to understand what they already have in GAM. Inventory mapping was a missing step.

The SOAP refactor into a modular package (mixin pattern) isn't visible to users, but it reduced the average time to diagnose a GAM bug from 45 minutes to under 10. That's the kind of invisible work that changes long-term velocity.

Before this release, deploying a native campaign to GAM meant juggling a dozen screens: creating the order, line items, uploading assets, configuring targeting, associating creatives. Every step was manual, every error required a partial rollback. The v1.3 pipeline automates the entire sequence from a creative ZIP. Real-time tracking via SSE lets you watch each step execute — not just a spinning loader.

Choosing FastAPI BackgroundTasks rather than an external orchestrator (Celery, Cloud Tasks) proved right for the current product size. Fewer moving parts, smaller attack surface, lower latency. We'll re-evaluate if volume demands it.

v1.0 answers a precise question: can you connect an AI agent to Google Ad Manager securely, without exposing service keys, without infrastructure to maintain on the user side? OAuth2 "on behalf of user" authentication with refresh tokens stored in Cloud KMS was the non-negotiable prerequisite. Without it, everything else is just a demo. The 2-step onboarding (account connection + GAM network) reflects that priority: shortening the path to the first real operation.

Scale-to-zero on Cloud Run from day one — not because it's the simplest solution, but because paying for idle instances while the product is in validation makes no sense. That constraint forced us to architect connections properly from the start.