onX x Virto Commerce
B2B commerce increasingly needs to talk to order management systems, fulfillment partners, and AI agents, and building a custom integration for every one of them doesn’t scale. Virto Commerce was the first commerce platform to go live with onX — the Commerce Operations Foundation’s open standard for order, inventory, and fulfillment operations — so one adapter connects to the entire onX ecosystem instead of one connector per partner.
About onX
Order Network eXchange (onX) is an open specification from the Commerce Operations Foundation, a vendor-neutral nonprofit, for how orders, inventory, and fulfillment events move between systems — commerce platforms, order management systems, warehouses, 3PLs, and AI-driven buying interfaces. Instead of every vendor building custom, point-to-point connections with every other vendor, onX gives the ecosystem a shared operational language.
Virto Commerce is a COF alliance member and was the first commerce platform vendor in the COF ecosystem to ship a live onX adapter, with production-tested contributions to COF’s reference MCP server implementation.
How Virto Integrates with onX
Virto’s onX adapter sits in a four-layer architecture — AI agents at the top, the MCP protocol layer, the MCP server, and the Virto adapter at the bottom, which translates MCP tool calls into Virto API requests and returns structured responses back up the chain.
The integration covers:
- Product search, pricing queries, cart creation, and order placement exposed as standardized, AI-callable tools through MCP
- Event-driven updates for real-time inventory and fulfillment status across connected systems
- A vendor-neutral connection point — any onX-compatible OMS, WMS, 3PL, or AI agent can connect without Virto-specific coding
- Integration with Virto’s xOrder and xCatalog APIs underneath the adapter layer
The adapter is open source, available on GitHub as the vc-onX-adapter repository, with configuration handled through environment variables and a documented permissions model mapping each operation to required Virto Commerce permissions.
Implementation Approach
Virto Commerce integrates with enterprise systems through a combination of APIs, middleware, and integration accelerators — designed to reduce implementation effort while preserving the flexibility that enterprise-specific workflows require.
The onX adapter follows this same model but as an open standard rather than a Virto-specific connector — configuration involves setting up the MCP server with API credentials for your Virto Commerce instance and store.
Key considerations: which onX-compatible systems need to connect, whether AI agents will be placing real orders or only querying data, required permissions for each operation type, and whether you’re connecting one partner system or building toward a multi-partner ecosystem.
Use Cases
AI-assisted sales ordering
A sales rep tells an AI agent to create an order for a specific customer and quantity. Through the onX adapter, the agent calls Virto’s product search, pricing, and cart creation tools via MCP, then submits the order — all without the agent needing to understand Virto’s underlying API.
Sales reps place verified orders conversationally, with live pricing and inventory, instead of navigating a separate order-entry interface.
Procurement automation
An AI agent monitors inventory levels and automatically checks stock and generates purchase orders when thresholds are hit. The onX adapter gives the agent a standardized way to query inventory and place orders across whichever fulfillment systems are connected.
Replenishment happens automatically based on real inventory data, without a person manually triggering each purchase order.
Connecting new OMS or 3PL partners without custom code
Onboarding a new fulfillment partner traditionally means building and maintaining a custom integration. Because onX is a shared standard, any onX-compatible OMS, WMS, or 3PL can connect to Virto through the same adapter — no partner-specific coding required.
New fulfillment partners connect in days rather than months, and one adapter continues to serve every additional partner added later.