Skip to main content
An ERP is usually the system of record for what a business owns and what it owes. OTO is the system of record for what is moving. Integrating them is mostly about agreeing where one ends.

Drawing the line

The integrations that go wrong are the ones where both systems believe they own the same fact. The ones that work draw a line and hold it.
Decide who owns stock, and mean itThis is the decision that determines whether the integration is calm or permanently in dispute. If the ERP owns stock, OTO reports movements and the ERP reconciles. If OTO owns stock, the ERP receives movements and does not overwrite them.What does not work is both writing stock levels for the same SKU at the same location. The symptom is figures that disagree in a pattern nobody can explain, and it is very hard to unpick once a quarter of history exists.

What crosses the line

Stock Management endpoints require the WMS add-on. Availability per plan is in the endpoint index.

The two identifiers that matter

Ten minutes with whoever owns the ERP, before the first hub is createdHub codes and SKUs are free to decide and expensive to change, because every integration, every import file and every historic record keys on them.The alternative is a renaming exercise six months in, with a mapping table somebody maintains by hand in between.

Three ways an ERP connection gets built

Unlike sales channels, ERP connections are not a self-serve catalog. There are three routes, and the third is the one most enterprise customers actually take.

Custom integrations built by OTO

Where a system has no ready-made connector — an in-house ERP, a bespoke WMS, an industry package nobody else runs — OTO can build the integration rather than hand you an API and wish you luck. The shape of it is simple: you expose endpoints, OTO integrates against them. The connector is developed for your account, to your business requirements, and maintained as part of your setup rather than as a project that finishes and decays.
The business rules are the long pole, not the codeWriting a connector against a documented endpoint is routine work. What takes the time is the set of decisions underneath it — and those are decisions about your business, so only you can make them.Bringing them already answered is the single biggest thing that shortens an integration: who owns stock, what a partial fulfillment means in your accounts, and whether an order is committed when it is placed or when it is picked. Teams that arrive with those settled integrate in a fraction of the time of teams that discover them during build.
This works in both directionsThe same approach covers systems that need to push into OTO (an ERP creating orders, a POS reporting stock) and systems that need to receive from it (a finance system taking shipment costs, a BI warehouse taking fulfillment events).It is also not limited to ERP. POS, WMS, in-house order managers and bespoke internal tools are all connected the same way.
Custom integrations are scoped commercially. Talk to your account contact, or write to support@tryoto.com with a description of the system and what you need to move between it and OTO.

Coming to the conversation prepared

If you are evaluating, the useful question to bring is not “do you integrate with X” but “here is which system owns stock, here are our site codes, here is the SKU convention, and here is what our ERP exposes”. That conversation is short. The other one is not.