Integrations
Adopting a platform should not mean throwing away everything that works. An integration here writes to the same Core OS records your own apps read — so there is no sync copy to keep in step and no second version of the truth.
How they work here
Most integrations are a scheduled copy between two systems that each believe they are right. That is where the drift comes from.
The usual arrangement
How OrbitWix does it
What connects today
What a category can do depends on what the other system exposes. These are the shapes we have connected; the specifics are worked out during implementation.
The record store OrbitWix reads and writes through. A business already running it keeps its data where it is and gains the platform on top.
Storefront orders arriving as sales orders, and availability published back from the same stock figure the warehouse works to.
Collection and settlement tied back to the invoice that caused it, so receivables clear themselves rather than being matched by hand.
Rates, labels and tracking held against the dispatch record, so a carrier update lands where your own team is already looking.
Business events reaching people where they already are — a dispatch leaving, an approval waiting, a payment received.
Anything that can call a REST endpoint or receive an event. This is how the systems that are not on this list get connected.
A note on ERPNext
OrbitWix reads and writes through ERPNext. That is worth being straightforward about, and worth putting in proportion: it is the record store underneath, in the same way a database is. It is not what you are buying.
Your data stays where it is. OrbitWix adds the Core OS structure, the connected apps and the workflows on top of records you already have.
Then it does not need to concern you. It is provisioned and maintained as part of the platform, and nothing about using OrbitWix requires knowing it is there.
They are not the same thing. ERPNext is a broad ERP you configure down to fit. OrbitWix is a Core OS plus the apps you switch on, built for trade, stock and movement in particular.
Building your own
Every integration above uses the same three mechanisms. Nothing is reserved for integrations we wrote ourselves.
Read and write Core OS records and app documents directly, under the same roles and permissions a person would be subject to.
The platform already emits an event when an order is confirmed or a dispatch leaves. A webhook is how another system hears about it.
For systems that cannot do either — and there are plenty — a file drop on a schedule is still a legitimate integration.
Permissions apply to integrations exactly as they apply to people: an integration acts as a user, with a role, and its changes appear in the same audit trail.
Keep it or replace it
Integrating a system keeps it alive, with everything that implies. Sometimes that is right and sometimes it is the expensive way to avoid a decision. Four questions we ask before connecting anything.
An accounting system your auditor requires is a keep. A tool one team uses out of habit is usually not.
One of the two has to be authoritative for each kind of record. If that cannot be decided, the integration will not hold.
Every integration fails eventually. The question is whether someone finds out immediately or at month-end.
Licence, maintenance and the ongoing attention of keeping two systems agreeing — weighed against moving that function onto the platform.
FAQ
Yes. Operations can move to OrbitWix while the books stay where your accountant wants them, with invoices and payments flowing between the two. Whether that is worth keeping in the long run is a judgement, not a technical limit.
No. ERPNext is the record store it reads and writes through, which is a real and worth-knowing technical fact. What OrbitWix is, though, is the Core OS structure, the connected apps, the workflow between them and the way trade, stock and movement are modelled — none of which comes out of the box.
It depends almost entirely on the other system. One with a documented API and a clear owner is days of work; one where nobody is sure how the data is structured is where the time goes. We scope each one during implementation rather than quoting a number in advance.
Yes, and it should be. An integration acts as a user with a role, so it can be scoped to one company, one branch or one kind of record, and everything it changes is written to the audit trail like any other change.
Have a different question? Talk to us.
We will say which should be integrated, which should be replaced, and which are costing you more to keep than to leave behind.