Reading from NetSuite,
and writing into it.
Through REST APIs and ODBC.
Oracle NetSuite is the system that is right about orders, items, customers and costs. Integrating it is two jobs at once: getting the data out in a shape other systems and people can actually use - its internal structure spreads a single entity across several tables - and writing back into it whatever is born elsewhere, an order from a portal, a customer record from an e-commerce. Both go through its REST APIs, and through one point in the middle.
What moves, and in which direction.
The technical question isn't which protocol - it is who owns the truth. For every piece of data you decide once, and you write it down in the mapping before writing any code. With NetSuite the source is almost always NetSuite; where something is born outside instead, it gets written in rather than re-typed.
- Customer and supplier recordsboth ways
- Read back recomposed into a single record. And if a customer is born in a portal or an e-commerce, it gets created in NetSuite instead of ending up in an email to the back office.
- Ordersboth ways
- History is read by date, customer and job. A new order - portal, e-commerce, the sales rep's web app - is written into NetSuite through the REST APIs.
- Items and price listsfrom NetSuite
- The information about one item, spread across several tables, becomes a readable row with no need to know the schema.
- Costs and cost centresfrom NetSuite
- The piece that makes the question that matters possible: what that client, that project, that job actually cost.
- Stock and movementsfrom NetSuite
- Stock levels and movements, kept as history: it is there to show the trend, not only today's snapshot.
- Documentsfrom NetSuite
- Invoices, delivery notes, order confirmations, available to whoever needs them without asking the back office.
These are the flows we have already put into production: examples, not a catalogue. In principle anything held in NetSuite can be read - on whichever of the two routes below fits; writes get decided case by case, and end up in the mapping before anyone starts.
Two routes, because they do two different jobs.
- // suiteanalytics connect · odbc
For reading at volume
When the job is getting a lot of data out - history, costs, movements - we read it through SuiteAnalytics Connect over ODBC: you query in SQL and pull in one go what would cost thousands of calls record by record. It has a property worth more than the speed: it is read-only by design, so NetSuite cannot be touched from that route even by accident.
- // rest apis
For a single record, and for writing
Anything about one record at a time - reading an order just created, writing a new one, updating a customer record - goes through the REST APIs. It is the only route that writes, which is why the list of what the layer may write is written down in the mapping.
Writes are designed to be repeatable without harm: if the network drops halfway, the order doesn't land in NetSuite twice. And every call, read or write, stays in the log - when someone asks why that record looks the way it does, the answer is a record and not a reconstruction from memory.
The ERP is right about the numbers. Not about the shape it keeps them in.
One point in the middle, not credentials scattered around.
The shortcut is to hand every tool the NetSuite credentials and let it get on with it. The next day you have four tools querying the ERP whenever they feel like it, nobody who knows who read or wrote what, and one heavy query slowing the system down at month end. The point in the middle imports, normalises, distributes - and writes only what it was asked to write.
- // shape
Normalisation, not a copy
We don't move NetSuite's tables somewhere else: we recompose them. An entity that lived across five tables becomes one record with a name, and from there a question becomes possible.
- // permissions
Per-role permissions
Who reads and who writes what is decided outside NetSuite. The e-commerce sees price lists and stock, not costs; an AI agent sees what it was granted and nothing else.
- // api
Controlled APIs, not keys in pockets
The other applications talk to the point in the middle, not to NetSuite. Nobody walks around with the ERP credentials, and every access goes through somewhere you can look.
- // writes
Explicit writes
What the layer may write into NetSuite is a project decision, written down in the mapping. It is not a blanket permission: it is a list, and outside that list the ERP is read-only.
We are not Oracle resellers and we take no commission on licences: we connect to its APIs the way we'd connect to any other system. If the problem is connecting NetSuite to other systems, the logic is the middleware one; if it is making its data readable and cross-referenceable, it is the data layer one - and with that layer in place, adding natural-language querying is one more piece, not a new project.
A real project, not a diagram.
One of the shapes this work takes - here the reading half, pushed all the way. An agency working in fashion and luxury events: NetSuite, the HR system and a set of spreadsheets lived in separate silos, each with its own logic. Today there is a single source, and anyone with a question writes it in plain language instead of opening a ticket, seeing only the data they are entitled to.
The questions we always get.
Do you write into NetSuite?
Yes, when the project calls for it: we do it through its REST APIs. But it is a decision taken in the open and written into the mapping, not a blanket permission: outside the list of things it may write, the layer is read-only. There are projects where it writes nothing at all - and that is why whoever owns the ERP can say yes without taking a risk.
Are you an Oracle partner or reseller?
No, and we take no commission on licences. We connect to NetSuite's APIs the way we'd connect to any other system. That is the whole advantage for you: when we say something isn't worth doing, we aren't defending a margin.
Do we need the SuiteAnalytics Connect licence?
Only if the ODBC route is worth taking, and it is a paid NetSuite module that we do not resell. Without it we read through the REST APIs: more calls for the same result, and at low volumes it makes no difference. The gap shows when there is a lot of data to pull - and the mapping, before any quote, says whether the licence is worth it in your case.
How long does it take?
It depends how many flows you actually need, and it is almost always fewer than it looks at the start. You begin with one - usually the records or the orders - put it in production, and add the rest once the first one holds. We don't ship six flows together on go-live day.
What if the data isn't only in NetSuite?
That is the normal case, not the exception: there is nearly always an HR application, an e-commerce, a few spreadsheets. The point in the middle exists to hold them together, and the questions that cross sources are the ones nobody could ask before.