Frequently Asked Questions

Shopping behavior is moving into AI assistants. Already, 73% of consumers are using AI in their shopping journey, and Accenture estimates that by 2030 more than 30% of online commerce – close to $3.1 trillion – will run through AI agents. If an AI can't see your products, it will recommend a competitor who is visible. Showing up isn't optional marketing. This is where the next purchase decision happens.

Different AI assistants and shopping platforms back different protocols, and no single one covers every surface. Supporting only one means you're invisible everywhere it isn't used. To reach as many shopping surfaces as possible, you generally need to support several protocols at once, which is why CorgiMaps maintains compliant surfaces across the major protocols from one place rather than one at a time.

Keeping up is continuous work, not a one-time task. Specs ship new releases, requirements change, and entirely new protocols keep emerging. Doing this by hand means tracking 6–12 evolving specifications and re-validating after every release. This is exactly what CorgiMaps maintains for you. It tracks the spec changes and keeps your endpoints compliant as they land, so your team doesn't have to monitor the protocols at all.

Frequently. Major releases tend to land on roughly a quarterly cadence, with smaller changes and activity happening as often as weekly across the protocols and their governing bodies. Because the space is young and moving fast, a surface that's compliant today can fall behind within a few weeks if no one is watching.

Yes. As new versions of AP2 are published and AI platforms deprecate support for older ones, a surface that was compliant can quietly stop working, and you may not notice until you've dropped out of AI results. Staying compliant means tracking every release and updating accordingly. CorgiMaps handles this version drift for you, keeping your AP2 surface current as the spec moves.

It reads how your site advertises AP2: the capability on your UCP profile, the signing keys the profile publishes, and whether your A2A Agent Card agrees with the profile. It also checks that the discovery document is served over HTTPS. It sends GET requests only and no credentials. It then lists what it cannot check without a live purchase, as rows marked "Requires a live purchase".

Only in part. This checker reads what you publish: the capability, the keys, and whether your card and profile agree. It cannot verify merchant_authorization on your checkout responses (those appear once AP2 is negotiated in a checkout session), mandate_required enforcement, SD-JWT and key-binding verification, open-mandate constraints, receipts or error codes. Those need a checkout or a real purchase, and this checker never starts a checkout or creates a cart, mandate or payment. Those six rows show as "—" and never count toward the score, so a clean run means the published surface looks right, not that you are AP2 conformant.

One JSON document: a UCP profile, an A2A Agent Card, the decoded claims of a mandate, or a receipt. Nothing is fetched, so checks that need a URL are skipped. For a mandate we check its kind and its schema, and that a checkout mandate's checkout_jwt looks like a compact JWS. We do not verify signatures. If you paste a raw SD-JWT (the compact string with ~ separators) instead of its decoded claims, we will ask you to decode it first. Paste runs are never stored.

No, it is a separate protocol, but it is designed to work with UCP. AP2 was created by Google and its specification says it is designed explicitly to be compatible with UCP. Merchants integrate it as an extension within UCP: on your profile it appears as the capability dev.ucp.common.payment.ap2_mandate, which extends dev.ucp.shopping.checkout. The older name dev.ucp.shopping.ap2_mandate still passes with a warning. Because that entry is a UCP capability, we validate it against UCP's capability schema.

In the top-level keys array of your UCP business profile, at /.well-known/ucp. Each one should be a public JWK, with no private members, and we look for at least one ECDSA key. A config.jwks_uri on the AP2 entry is not a UCP field, so UCP verifiers do not read it; if you have one, we only compare its key ids with your keys array. Signing keys are not published on the Agent Card.