Protocols & compatibility
Protocol layers vary in status (see below), and none of them replaces the default public integration model. External developers should start with API keys, REST endpoints, and webhook delivery, then introduce protocol layers only when a partner program or rollout stage explicitly requires them.
Status as of 8 October 2026. Pivota does not author any of these standards.
Tool and context interface
MCP connects AI applications to tools and context. Pivota exposes four public research tools; keyed checkout requires buyer identity and merchant readiness. MCP does not settle funds or guarantee a tool is implemented.
Hosted seller door, any agent with a portal API key
Pivota runs a hosted UCP seller door: discover it at commerce.mcp.pivota.cc/.well-known/ucp, then search and read the catalog with your developer-portal key. Checkout through the door is limited: it needs OAuth buyer identity and merchant readiness. Pivota's decision layer is published as the vendor capability cc.pivota.insights.
Selected technical-partner workflows
ACP coordinates commerce and checkout interoperability and is a protocol layer used in selected LLM and partner workflows. Core APIs and webhooks remain the production control surface.
Selected partner and payment workflows
AP2 provides verifiable delegated-payment authorization and trust; it is a protocol layer above standard order and webhook flows. It is not a public self-serve surface in the default developer path.
Visa Intelligent Commerce, Visa Trusted Agent Protocol, Mastercard Agent Pay
Pivota does not support these programs. Card acceptance stays with the merchant's own payment providers.
Treat REST APIs, API keys, order flows, and webhooks as the production control surface. Standards and protocol layers sit above those operational surfaces and should not be treated as a replacement for them.