Platform capability
Connect the systems that run your commerce. Once.
Connectivity is the connection layer of the mPorts platform, delivered as part of mPorts OMS. The marketplaces and retailers orders arrive from, the warehouses and third-party logistics providers that ship them, the carriers that carry them, and your own business systems each connect to mPorts once. Everything mPorts does — the OMS, Distribution and AI operations — shares that connection, so a system is added in one place, checked in one place, and feeds one operating picture of the business.
mPorts connectivity
Why one engine instead of many separate connections
The obvious way to connect systems is the direct way: whichever application needs a marketplace talks to that marketplace itself. It is the fastest way to your first connection and the slowest way to your twentieth.
Separate connections multiply. Each application ends up holding its own logins, its own retry behaviour, its own idea of what a failed request means. When something breaks, "where does this talk to them?" has as many answers as you have applications.
What sits where
- Places you sell
- Warehouses & 3PLs
- Carriers & tracking
- Business systems
- mPorts connectivity
- Products & listings
- Orders
- Inventory
- Shipments
- Costs
- mPorts OMS
- mPorts Distribution
- AI operations
Kinds of system mPorts connects with. Which specific systems are connected today, and how far each connection goes, is on the integrations pages.
What this buys you day to day
One place to add a system. One place to look when a system misbehaves. One set of logins to keep safe, rather than several sets kept in several places.
It also keeps the rest of the software simpler: mPorts OMS asks for what it needs in its own terms, and the engine is the part that knows how a particular outside system expects to be spoken to.
- Marketplaces and commerce channels
- Warehouse and third-party logistics systems
- Carriers and tracking providers
- Application APIs
Which systems, exactly
Each connected system has its own page: what comes into mPorts, what mPorts can send back, and where the connection stops. That is where to check whether the systems you run are covered.
Connecting your ERP is scoped per account; ask us and we will say what it takes.
One outage, worked end to end
A warehouse system stops acknowledging submissions overnight.
-
Signal
Submissions to one warehouse system go unacknowledged while every other connection is healthy.
-
What mPorts shows
The connection’s health in one place, and the orders waiting on it.
-
Investigation
Whether the failure is the connection, the warehouse, or a change in what the warehouse expects.
-
Recommendation
Hold the affected submissions, or reroute the urgent ones to another location that has the stock.
-
Approval
An operator decides. A reroute is a decision about the order, not a setting.
-
Action
Held submissions resume through the same connection once it recovers; rerouted orders replan.
-
Record
The outage, the decision and the resubmissions are recorded against the orders they touched.
Questions buyers ask
Is our system supported?
Ask us and we will check against the live connections. Each integration page says exactly what its connection does.
How is connectivity priced?
It is part of mPorts OMS. Each system connects to mPorts once and everything the OMS does shares that connection; there is nothing separate to buy for it.
Do you support EDI?
Yes. mPorts connects to retailers over EDI — purchase orders, acknowledgments, shipment notices and invoices — and the orders those documents create are operated alongside every other channel. Which retailers, and in which format, is a scoping conversation: large retailers each specify their own.
Where do the logins live?
With the integration engine, rather than scattered across each application. That is one of the main day-to-day reasons for keeping the connection in one place.