Oracle NetSuite Integrations

Which NetSuite data the online store needs

In NetSuite, eCommerce relies on very specific records. Items can be inventory, non-inventory, kits or matrix items with their variants, and each type is published on the store differently. Stock is read per location, and in OneWorld accounts each subsidiary has its own locations, currency and taxes, which determines which store sells what and where it ships from.

Customers carry their subsidiary, price level, payment terms and credit limit. For B2B, the contacts at the customer company also matter, because on the store each person logs in with their own user but buys on behalf of the same account. In B2C, by contrast, many buyers check out as guests, and you have to decide whether to create a customer per buyer or group them under a generic customer, which affects NetSuite's reports and CRM.

Prices also call for a decision: NetSuite combines price levels, quantity pricing and customer- or group-specific prices. Depending on the number of customers and how often terms change, the store either replicates those rules or asks NetSuite for the price when showing the cart.

SuiteTalk, REST and RESTlets: how we connect to NetSuite

NetSuite offers several routes. SuiteTalk groups the SOAP and REST web services for reading and writing standard records; the REST API also includes SuiteQL queries to extract data efficiently. RESTlets are custom endpoints written in SuiteScript, useful when an operation needs to apply several rules inside NetSuite in a single call.

Authentication uses tokens or OAuth 2.0, through an integration role with just the permissions it needs. You have to bear in mind the account's concurrency limits: if several systems call at once, requests are rejected. That is why we group operations, use saved searches or SuiteQL for bulk reads and centralise calls in a queue that respects those limits. To learn about changes without constant polling, NetSuite can run a script when a record is modified and notify the integration; for large catalogues an incremental read by last-modified date also pays off.

Orders, payments and fulfilment in NetSuite

The web order enters NetSuite as a sales order, with the subsidiary, location and shipping method already resolved. From there the cycle continues in the ERP: picking and dispatch are recorded as a fulfilment, and billing generates the invoice or cash sale depending on the payment model.

The gateway payment is recorded in NetSuite as a customer deposit or payment linked to the order, so finance can reconcile without searching by hand. Returns follow the return authorisation and credit circuit, and the store receives the status of each step.

In international operations the integration respects the subsidiary's and the customer's currency, and leaves tax calculation wherever you have it configured. If you also sell on marketplaces, each order carries its channel so you can later filter each one's sales in NetSuite.

How we run a NetSuite integration project

We work against a NetSuite sandbox account and never directly on production. The record and field mapping, including any custom fields in your account, is validated by your NetSuite administrator or partner before development.

Oracle updates NetSuite twice a year. Before each update we go through the release notes and test the critical flows in the release preview account, so the store doesn't notice the change. When the project closes we hand over documentation for each flow and set up alerts for errors that need intervention, so finance or IT know what to check.

We connect NetSuite with Adobe Commerce (Magento), Shopify, VTEX and BigCommerce, and with custom-built B2B portals.