A video-buy integration can accept a proposal, create an order and still deliver a creative that the destination player cannot use. The failure becomes expensive when every component reports success and the team has no record connecting those responses.
That is a useful starting point for comparing AAMP and AdCP. A feature list helps with discovery. An implementation review needs to show how a specific brief becomes an executable buy, which system owns each decision and what evidence survives the handoffs.
This walkthrough uses a synthetic video campaign. Its identifiers and evidence format are application examples, not fields defined by either protocol.
Compare the releases you can actually implement
As of October 25, 2026, IAB Tech Lab's AAMP 3.0 announcement places OpenProposal at the proposal stage and connects it to established transaction standards, including OpenDirect and the Deals API. The announcement currently extends OpenProposal's public comment period to November 10. That status belongs beside any implementation claim.
AAO's October update describes AdCP 3.2 and its activation capabilities. It identifies reporting, clean-room activation and rights attestations as experimental. A capability appearing in documentation does not establish that your selected seller implements it, or that an experimental contract will remain unchanged.
Keep three versions in your evaluation notes: the protocol release, the SDK release and the implementation you tested. An SDK upgrade alone cannot establish that a remote platform supports a new operation.
For each requirement, record a documentation reference and an observed result. If you only have a roadmap statement, label it as such. This makes the comparison maintainable when the next release arrives.
Start with a brief that has testable constraints
Suppose the buyer wants a fifteen-second video campaign in one market, with a fixed budget, an approved creative revision and a verification requirement. The seller offers an inventory package and a delivery path that uses VAST.
Write the acceptance conditions before running an agent:
- The accepted package covers the requested market and dates.
- The activated order uses the agreed budget and creative revision.
- The serving URL resolves to a usable creative for the selected player profile.
- The integration can identify the observation supporting its delivery claim.
These conditions cross several systems. A proposal response can support the first condition without establishing the others. An order identifier is useful, but it does not show which bytes the player eventually retrieved.
Also state what the brief does not specify. If reporting freshness, permitted substitutions or creative approval ownership are undecided, preserve that uncertainty. Letting an agent fill those gaps with plausible defaults creates an agreement nobody explicitly reviewed.
Map the work before mapping protocol operations
Use the same review structure for both candidate integrations:
Buyer brief and seller product description
|
Proposal evaluation and accepted terms
|
Order creation or platform activation
|
Serving URL and resolved creative revision
|
Player observation and delivery reporting
This is a review map, not a protocol state machine. Some buys use different transaction infrastructure. Some products do not use an OpenRTB auction or VAST at all. Map the real execution path rather than forcing every product into one architecture.
At each boundary, ask who owns the next action. The proposal service may describe an inventory package while another service activates it. The creative URL may be supplied by a third party. The player observation may live in an SDK log that the buying agent never receives.
Those boundaries determine where your integration needs adapters, correlation identifiers and failure handling. They are often more consequential than whether two APIs use similar operation names.
Keep a compact evidence record for one buy
The following JSON is an application-owned index. It references artifacts rather than attempting to reproduce an entire protocol payload:
{
"review_id": "synthetic-video-buy-001",
"brief_revision": "brief-3",
"proposal_revision": "proposal-7",
"accepted_terms_artifact": "terms-7.json",
"activation_reference": "synthetic-order-42",
"creative_revision": "creative-12",
"creative_check_artifact": "creative-12-check.json",
"player_observation_artifact": "player-run-8.json",
"reviewed_at": "2026-10-25T16:00:00Z"
}
The relationship between the files matters more than their filenames. Can the activation record be traced to the accepted terms? Does the creative check identify the revision used by that activation? Does the player observation refer to the same serving input and environment?
Use content hashes where an identifier could remain stable while bytes change. Keep the original artifacts in controlled storage. The index should help a reviewer find the evidence without turning the operational log into a collection of credentials and complete request bodies.
Exercise failures that a successful demo leaves out
Start by changing the creative after proposal acceptance. If the order still refers to the earlier revision, the system should expose that disagreement. A previously clean validation report cannot approve a later creative merely because the URL stayed the same.
Next, retry an activation after simulating a lost response. Record the integration's documented retry mechanism and verify that the retry refers to the intended transaction. Do not assume that a locally generated request identifier automatically provides remote idempotency.
Then make the reporting result unavailable. Preserve a distinction between missing data and a measured zero. They lead to different operational decisions, and an agent should not silently convert one into the other.
Finally, use a creative that is structurally valid but incompatible with the target player's rendition requirements. This reveals whether the integration has a real creative acceptance boundary or merely forwards a URL.
These are test scenarios, not claims about defects in either framework. Run them against the implementations you are evaluating and retain the observed results.
Make the comparison actionable for your team
For every required stage, record the responsible service, supported release, evidence location and recovery action. A requirement without an owner is unfinished integration work. A stage with no preserved result is difficult to audit even when it appears to function.
Choose based on the systems your buyers and sellers can operate, the capabilities your products require and the work needed to close those gaps. A protocol comparison becomes useful when it produces that implementation plan.
I maintain VASTlint. For the VAST-serving branch of this workflow, the AdCP integration reference explains where creative inspection fits. Attach that result to the creative revision and player observation, so it answers a specific acceptance question in the buy.
Sources
Technical sources checked October 25, 2026. Drafted with AI; examples are synthetic unless explicitly stated otherwise.
Top comments (0)