Docs

Gate order

Troubleshooting

• The call answers DENY_MARKET. — The ship-to is not one of the 20 markets, or an EU code came without a member (use EU-DE, not EU). UK is written UK for people and stored GB in machine fields; both are accepted as input.
• The call answers DENY_NOT_VERIFIED or GATE_REQUIRED. — Buyer, supplier, price, availability, documents, order and handoff tools need the decision_id of an allow decision. Call resolve_jurisdiction → resolve_actor → gate_transaction first and pass its decision_id.
• The call answers DENY_UNLICENSED_AGENT. — The three write tools (create_order_intent, a2a_handoff, log_audit) need a registry bearer: register once at https://a2a-registry.ai/oauth/register (RFC 7591) with hub 'grocery', mint a client-credentials token at https://a2a-registry.ai/oauth/token with scope grocery.transact (grocery.read and grocery.audit are read-only and are refused by the write tools), present it as Authorization: Bearer.
• The call answers DENY_ACTOR_CLASS. — The door is trade only. public and consumer are refused; use maker, brand_owner, private_label, distributor, importer, broker, retailer_buyer, auditor (read-only) or agent (with the credential of the class it acts for).
• BAD_INPUT on an id or a filter. — Ids are never empty: a GTIN of 8–14 digits or the catalogue id from search_cleared_items; a quantity is a whole number from 1 to 100000; since is YYYY, YYYY-MM or YYYY-MM-DD; temperature is ambient · chilled · frozen · fresh; lane is organic · free-from · plant-based · artisan · origin · premium; channel is discounter · e-commerce · local · in-store · traditional.
• My client rejects the tool schemas. — The schemas are open (no additionalProperties:false, no oneOf) so the stock clients of the three major clouds attach without an adapter. The stock google-genai SDK deep-copies its config object; pass the config as a dict when attaching this door as a tool.
• I get HTTP 402 from the hub's /api. — That is the x402 offer, not an error: the metered call settles in USDC on Base through the facilitator named in the offer; the receipt is signed and resolves forever at the payments door.
• Counts on the page and in my answers differ. — Every count is produced from the record at request time; the page bakes the count at build and refreshes it from the door's health in the browser. A difference means the record moved since the last build.

Data handling

• What is stored — Request logs at the origin (method, path, status, timing — no message bodies); x402 receipts, agent registrations (client id, name, contact, scope), audit entries (client id, tool or skill, outcome, UTC day) and sealed review packs; the record itself (SKUs, Chains, HITL documents, Economics, Makers, Acts), every field with its source page, read date and source class.
• For how long — Origin console logs: the retention set on the Log Analytics workspace that receives them (read at the first roll). Receipts, registrations, audit entries and packs: no retention period is configured — no lifecycle policy, soft delete off — so they are kept until the operator removes them. There is no database behind this hub and no backup schedule: the record is a set of files built into the door and held on the operator's systems.
• Where — Microsoft Azure, South Central US: the door, the hub, the issuer, the payments door and one storage account for receipts, registrations, audit entries and packs. Cloudflare handles DNS, TLS, caching and request handling at the edge. Form submissions go to the form provider and the operator's mailbox. Payment verification and settlement run through the x402 facilitator on Base.
• What is never stored — Consumer data: the door is trade only and refuses public and consumer actors. Message bodies of tool calls are not logged. No name of a maker, banner or retailer renders on any web page; names live on the door and the agents only. Licensed third-party figures a tenant loads stay in that tenant's record and are never redistributed.