Comparisons
Compare Openship's self-hosted routing model with hosted and custom order-routing approaches.
Openship is a self-hosted order-routing application. It stores shops, channels, links, matches, orders, and downstream purchase state, then invokes configured adapter operations to read source orders and place fulfillment purchases.
Its main distinction from a hosted order-management service is ownership: you operate the source, database, deployment, credentials, adapter destinations, retries, and reconciliation.
Compare operating models
| Approach | Integration boundary | Operations responsibility | Typical tradeoff |
|---|---|---|---|
| Openship | Built-in or configured shop/channel adapter operations | The operator owns deployment, credentials, routing behavior, and recovery | Source-level control with corresponding engineering and operational work |
| Hosted order-management service | Vendor connectors, rules, webhooks, and APIs | The vendor operates the core service; the customer configures it | Less core infrastructure work, within the vendor's connector and rule model |
| Marketplace or store routing app | One platform's extension surface | Shared between the app vendor and merchant | Faster fit for supported platform workflows, with a narrower platform boundary |
| Custom routing service | Contracts and workflows designed by the implementing team | Entirely owned by that team | Maximum freedom without Openship's existing models, dashboard, and adapter executors |
Compare exact connectors, cancellation and fulfillment behavior, retry semantics, audit evidence, support, and total operating cost—not category labels alone.
Current Openship integration scope
Current compiled source includes Shopify and Openfront handlers on both shop and channel sides. Platform records can also configure operation destinations for independent HTTP route apps or local modules, subject to the executor's contract.
That architecture is extensible, but it is not the same as verified compatibility with every commerce or fulfillment system. Each additional platform needs implementations for the operations it uses, authentication and credential handling, payload validation, webhook verification, idempotency, timeout and retry policy, and reconciliation tests.
Routing behavior
Openship can:
- record source orders and their line items;
- select configured shop-to-channel links using link filters and rank;
- use saved item matches to build downstream cart items;
- call channel adapters to create purchases;
- retain status and error information for operator review.
Delivery latency depends on webhook or polling behavior, queueing, provider availability, and the configured execution path. Current source does not establish a universal real-time delivery guarantee.
Cost and setup
Open source does not mean zero operating cost or setup in a fixed number of minutes. A useful evaluation needs a database, deployment, operator account, credentials, shop/channel records, links or matches, webhook configuration, and a tested failure-and-reconciliation path.
Infrastructure, provider, marketplace, support, monitoring, and implementation charges remain deployment-specific.
When Openship may fit
Consider Openship when a team:
- wants to own and modify its order-routing source and data;
- has a supported adapter or is prepared to implement and test one;
- needs explicit shop, channel, link, match, and downstream purchase records;
- can operate retries, reconciliation, credential rotation, and webhook verification.
A hosted or platform-specific alternative may fit better when a required connector, service-level agreement, support program, reporting suite, or compliance program already exists there and source-level customization is not required.