NetSuite ecommerce integration without starting on SOAP

The store already takes orders. NetSuite already holds customers, items, subsidiaries, and tax. The gap is SuiteTalk REST — salesOrder, invoice, and who fulfils. We will tell you what REST will take, and what a SOAP script should not be asked to do next.

Book a free 30-minute discovery callTalk through your NetSuite connection

Australian ecommerce team. We look at the store and the NetSuite account before anyone talks about a connector.

Still running a store that needs NetSuite?

The store still takes orders. NetSuite still holds the subsidiary. That is why the two have been left talking through a saved search, or through a SOAP integration Oracle has already dated for removal.

Oracle NetSuite is cloud ERP — financials, CRM, inventory, orders — used globally, including AU and NZ subsidiaries. Oracle publishes an ANZ Localization SuiteApp (BAS, NZ GST101A, PTR, TPAR, ABN list) and lists a Sydney office at North Ryde. That is product and office presence, not an Australian customer count. We will not invent “leading mid-market ERP in Australia” as a share figure.

You might recognise one of these:

  • Web orders are re-keyed as sales orders because the last SOAP job is fragile
  • Custom fields and a second subsidiary were never in the original mapping
  • Tax on the storefront does not match the ANZ SuiteApp fields NetSuite posts
  • Someone wants a new SOAP build because “that is how NetSuite integrations work”
  • Item fulfilment and invoice are different transforms, and only one of them was scoped
  • The store and NetSuite each think they own the customer record

You do not need a new storefront, or an Oracle sales pitch. You need a clear read on the NetSuite account you already have.

Why these connections stall

NetSuite has official web services. The stall is rarely “there is no API”. It is which API Oracle still wants you to use, and the custom fields every AU multi-entity account grows.

REST not SOAP

OAuth 2.0

Subsidiaries

Transform, don’t guess

New work should be SuiteTalk REST, not SOAP.

SuiteTalk REST Web Services are what Oracle recommends for new integrations. Record URL shape: https://{accountId}.suitetalk.api.netsuite.com/services/rest/record/v1/{recordType}. Ecommerce-relevant REST records include salesOrder (salesorder), invoice, and customer. You can transform a sales order to an invoice or to item fulfilment. SuiteQL is available at POST /services/rest/query/v1/suiteql when a record GET is the wrong shape. SuiteTalk SOAP still exists. Oracle has scheduled removal: 2025.2 is the last planned SOAP endpoint; from 2027.1 only 2025.2 SOAP is supported; SOAP is unavailable from 2028.2. A new store project that starts on SOAP is buying a rewrite.

OAuth 2.0 is the preferred door. TBA is the other one, not a shared secret in a plugin config.

REST auth is OAuth 2.0 (preferred) or token-based authentication. Account id, integration record, and role permissions decide what the store is allowed to write. A role that can create a sales order but cannot set a custom tax field will fail in production and pass in a demo.

Subsidiaries and custom fields are normal, not edge cases.

AU multi-entity orgs routinely have more than one subsidiary, plus custom fields the SuiteApp and the partner piled on. A generic “create salesOrder” mapping that ignores subsidiary, location, and custom column fields will post and then fail fulfilment. The ANZ Localization SuiteApp is why BAS, GST101A, PTR, TPAR and ABN list fields exist — drop them and the books people will bounce the order.

Sales order is not the invoice, and it is not fulfilment.

The REST model expects you to create the salesOrder, then transform to item fulfilment or invoice when the business says so. A store that posts an invoice because checkout succeeded, while warehouse still needs a fulfilment, is how NetSuite and the floor disagree.

None of that makes the item master or the store worthless. It does mean “one more SOAP operation on Monday” is usually the wrong first move.

How we work

We start with the NetSuite account and the store, not with a SOAP notebook from 2019.

1

Look at what you have

Store platform, account id, subsidiaries, ANZ SuiteApp, custom fields on customer / item / sales order, and whether anything still calls SOAP. We will tell you whether the first write is a salesOrder, and who is allowed to transform it.

2

Decide the job

There are three honest outcomes. We recommend one, not all three.

3

Do the work in stages

Customer and item master first, then salesOrder, then fulfilment or invoice transform. A sandbox account beats a Friday post into the live subsidiary.

4

Hand it back so the next person can run it

Source, the integration record and role, and a short record of which REST record creates which document.

Three honest outcomes

  • Connect the store to NetSuite on SuiteTalk REST and OAuth 2.0: customer and item master, POST salesOrder, then transform to invoice or item fulfilment, with ANZ tax fields included. Custom API work. No published CoSource NetSuite connector.
  • Fix a broken connector when SOAP or an old TBA script still almost works: move new traffic to REST, stop dropping custom fields, and stop double-creating customers across subsidiaries.
  • Decide not to connect when a SuiteApp or Oracle commerce connector already owns the storefront posting, when the account is mid-implementation, or when the store should only read items and orders should stay in NetSuite.

We will not start a new SOAP build. We will not invent a NetSuite case study. If you already have a NetSuite partner who owns SuiteCommerce or the official connector, they may be the better first call on the ERP side. If you want an honest fork in the road on the store, talk to us.

What we need for the first call

A store URL and which NetSuite account is enough to start.

  • Which store: nopCommerce, AbleCommerce, Shopify, or another CMS
  • Account id, subsidiaries, and whether the ANZ Localization SuiteApp is installed
  • What should sync: customers, items, salesOrders, invoices, fulfilments
  • Whether anything still uses SuiteTalk SOAP, and when it last ran
  • Custom fields the warehouse or finance team will not give up
  • What “done” looks like: a working REST sync, a repaired connector, or a clear picture first

The first call is 30 minutes. You leave with a recommendation you can take to a manager, not a NetSuite estimate pulled from thin air.

Related work

We have not published a NetSuite ecommerce case. NESS is nopCommerce and Dynamics NAV 2018. Windsor is nopCommerce, Peach, and Peach↔Xero. Neither is NetSuite, and we will not stretch them.

CoSource is a Sydney software firm and a nopCommerce Gold Partner. Services include CRM & ERP integration on nopCommerce, AbleCommerce, and Shopify. That is a capability, not a NetSuite case study. A NetSuite account still starts with its own assessment.

FAQ

Should a new integration still use SOAP?
No. Oracle recommends SuiteTalk REST for new work. SOAP has a published removal path ending 2028.2. We will not design a new store job on an API that date is already on.
Can the store create a NetSuite sales order?
Yes, on REST, as salesorder. Invoice and item fulfilment are transforms from that record, not a second guess at checkout.
What about Australian tax and BAS?
Oracle’s ANZ Localization SuiteApp is the vendor’s answer for BAS, NZ GST101A, PTR, TPAR and ABN list. The mapping has to include the fields you actually use. We do not have an AU customer count to quote.
Do you have a NetSuite store case?
No. We will not invent one.
We have a lot of custom fields.
That is common on AU multi-entity accounts. Bring a list of the ones fulfilment and finance will reject the order without.

Talk through the NetSuite connection you already need

Thirty minutes. Bring a store URL and the account id if you have it. We will tell you whether to connect on REST, retire SOAP, or leave posting inside NetSuite.

Book a free 30-minute discovery call