My co-founder Mo Afshar recently wrote about why Pipe17 co-founded the Order Network eXchange (onX). He focused on why commerce operations need a common language. As Pipe17’s CTO and a member of the Commerce Operations Foundation’s Board of Directors and Technical Steering Committee, I want to share how onX actually works under the hood. And why we built it using an open-source model.
Explore our latest announcement on Pipe17’s completed onX implementation, highlighting operational availability and customer enablement.
Table of Contents
Why Open Source? Lessons from the Cloud and Big Data
Before diving into architecture, it’s worth understanding our technical philosophy. Open-source standardization has proven successful at massive scale:
- OpenStack standardized cloud compute
- Hadoop established the foundation for big data processing
- Kafka became the backbone for event streaming
These projects succeeded because they were shepherded by vendor-neutral foundations like the Apache Software Foundation. The foundation model creates transparency. No single company can control the standard. Competing vendors collaborate on equal footing.
The Order Network eXchange (onX) follows the same playbook. It’s not proprietary software dressed up as a standard. It’s genuinely open-source code governed by the Commerce Operations Foundation. This is an independent nonprofit where brands, 3PLs, platforms, and technology vendors collaborate on how commerce systems work together.
The Core Use Cases onX Standardizes
Every standardization effort needs boundaries. We focused onX’s first iteration on the four pillars of commerce operations:
- Capturing orders across all channels and marketplaces
- Providing fulfillment through warehouses, 3PLs, and logistics providers
- Syncing inventory in real-time across all locations
- Reading products and catalog data across systems
After connecting hundreds of commerce systems at Pipe17, we identified these as the operations that break most often. They cost the most to maintain. They create the biggest bottlenecks to growth.
The Commerce Operations Foundation’s Technical Steering Committee will shepherd which use cases we standardize next. But these 4 pillars cover the critical path for most commerce operations today.
onX Architecture: Built for Extensibility
The onX reference implementation consists of four key components available on GitHub:
Schemas
Define standardized data structures for commerce objects: orders, products, inventory, fulfillments, customers, returns.
These schemas represent common fields we’ve observed across hundreds of different systems. Every order has an ID, status, line items, and customer information. The specific field names vary, but the concepts are universal.
onX schemas capture these universals while remaining extensible for system-specific needs.
Tools
Define structured inputs for standardized actions like cancel_order, create_sales_order, fulfill_order, get_customers, get_fulfillment, get_inventory, get_orders, get_products, and update_order.
Think of these as the standard verbs for commerce operations and fulfillment.
Server
The onX MCP server implementation is built on the official Model Context Protocol TypeScript SDK.
TypeScript is currently the most popular language for MCP implementations. The server handles all MCP interaction complexity, including a service layer that manages client communication, session management, and data orchestration. It manages how clients discover available tools, routes requests, and formats responses.
Adapters
onX defines a generic schema for orders. But every system has its own order schema: ChatGPT, Shopify, Amazon, Pipe17, ShipHero, NetSuite. onX adapters bridge this gap.
Companies implement onX by building their own adapters. Each adapter serves as that company’s onX implementation. The Pipe17 adapter is how Pipe17 implements onX, the Manhattan adapter is how Manhattan implements it. These adapters translate between onX’s standardized format and the company’s specific data models and APIs.
How onX Adapters Work
Every company hosts their own MCP server with their onX adapter. When a client needs inventory data from Pipe17, it connects to Pipe17’s MCP server and makes a get_inventory request using onX’s standardized format. Pipe17’s onX adapter translates the request to Pipe17’s schema, retrieves the data, maps it to onX’s schema, and returns it. If the client needs data from Manhattan, it connects to Manhattan’s MCP server that’s running their onX adapter.
The client always receives consistently formatted data, regardless of which company provides it.
Individual companies implementing onX only need to build their adapter template to bridge onX specifications to their application. They don’t need to modify the reference server or build one from scratch.
The adapter framework also supports extending beyond the core specification while maintaining onX compatibility:
- Expose additional fields
- Implement extra tools
- Add capabilities specific to your system
Built for the Agentic Commerce Era
This open source, extensible architecture matters because AI is rapidly reshaping commerce operations. Edgar, Dunn & Company projects agentic commerce could reach $1.7 trillion by 2030.
AI agents executing fulfillment workflows need to query inventory, evaluate shipping options, update order status, and handle exceptions across systems with different APIs and data formats. Without standardization, an agent serving 50 brands needs 50 different implementations for each operation. This doesn’t scale.
onX solves this at the protocol layer. Built on the Model Context Protocol, it gives AI agents a single interface to commerce operations. The agent makes one get_inventory call using standardized input. The adapter translates to the system’s specific API. The agent receives consistent data regardless of source.
Because onX is open source and community-governed, AI developers build against a stable specification without vendor dependencies. For production environments requiring predictable interfaces and guaranteed data structures, standards eliminate complexity.
Pipe17’s Commitment to Open Standards
At Pipe17, we’re currently evolving our MCP server to use onX as the foundation. We’ll host our own onX implementation with a Pipe17 adapter, and plan to open-source our adapter as a reference onX implementation for other companies.
We’re also actively participating in the Commerce Operations Foundation’s technical working groups to help shape the onX standard itself. Specifications benefit when companies implementing them in production provide feedback on what works and what needs refinement.
Our goal is to accelerate onX adoption by sharing what we’ve learned about things like performance optimization, error handling patterns, and scaling considerations from processing millions of orders. By standardizing the protocol layer, onX enables Pipe17 and other member companies to focus on what actually matters: intelligent orchestration, exception handling, inventory management, and AI-powered optimization.
Book a demo to see how Pipe17 is delivering AI-native order orchestration capabilities today with our MCP server, Pippen AI agent, multi-location inventory management and dynamic order routing.
