Bla bla bla, so what? NetSuite’s planned updates for integration --part III

The changes to NetSuite’s integration architecture announced in the Release Upgrade Notes 2026.1 also have a direct impact on integration methods for transaction processing, meaning integrations with CRM systems such as Salesforce or HubSpot, web stores such as Shopify and Magento, booking systems such as cvent or TravelPerk, and payment solutions such as PayPal, Stripe, Checkout, Adyen and so forth.

If you havent read our article in part I and part II , you might want to do so before you continue to our integration information below.

The reason is that such integrations are best run through webhooks, and with the requirement for a JWT grant type required for RESTlets, receiving such webhook messages becomes unlikely.

Let's quickly review why webhooks are so essential for ERP integration use cases. (If you want to jump to the conclusions, go straight ahead to the “Bla bla bla, so what” paragraph.)

When it comes to integrating cloud business software for transaction processing, webhook-based web services have come to be the go-to approach in terms of efficiency, scalability, and resilience. The idea of webhook-based integration is that the source system automatically notifies the target system whenever a specific event occurs, is triggered, as we say. What events on what business objects (data types) shall be triggered is predefined by the system administrator or integration specialist. Any trigger is therefore record- and event-specific, a separate webhook message per data record and event. Subsequently, the target system is notified of which record was changed in what way, and can execute logic (or downright replicate the event) in its own API.

Webhook-based integrations are highly resilient because they execute logic on a single business event of a single business object in real-time. We refer to this approach as the “real-time single-record mantra”. If an error occurs in the integration, said error affects the execution of only one record for one specific event. Accordingly, error logging is straightforward because we know exactly which instance of a business record is affected. Executing remediating functions or triggering alerts is thus also straightforward. The more complex the data models, the more important such simplicity in execution is.

Webhook-based integration is hence the established integration method for any (good) high-frequency transaction system, order management systems such as Shopify and Magento or payment gateways such as PayPal, Stripe, Adyen, Checkout basically all of them. The approach has also been adopted by other booking-related systems, event software such as cVent or travel booking software such as Perk.

Surprisingly, though, despite the straightforward nature and telling advantages, webhooks have not been adopted as the go-to approach in other areas of business software - and strikingly, especially not ERP. This is striking because ERP modules are meant to be the system of record, the golden source, and thus would want to receive, store, and process business data as swiftly as possible in the most powerful databases the information age offers.

Most strikingly, NetSuite is no exception to conflicts with the webhook-based integration approach. Yes, NetSuite allows for outgoing webhook notifications via SuiteScript (module N/https with method https.post) for about 20 years already, and those executions are limited only by the overall SuiteScript governance limit. (For example, the execution of a User Event script offers 1000 governance units and calling https.post consumes 10 governance units, theoretically, you can execute about 100 webhook messages out of a user event script. You never want to do that; in fact, you wouldn’t want to execute it directly within a user event script in the first place.) However, since ERP systems are much more about receiving webhook messages from upstream business applications, we are in need of web service endpoints that can receive incoming webhook messages. For that purpose, NetSuite has not introduced any straightforward or scalable method to publish such endpoints, neither via SuiteScript nor via any dedicated addon module. Yes, NetSuite SuiteScript offers Suitelets and RESTlets, which both allow for publishing endpoints. However, publishing Suitelets is limited to the GET method (read “getting” data) for purposes of online forms, and the use of those GET endpoints for webhook messaging is explicitly forbidden in the documentation. RESTlets allow for both GET and POST methods (read “posting” data into NetSuite), but this is where the complex authentication methods of NetSuite come into play.

Webhook messages are all about quick notifications: fire and forget. Security and scalability are meant to be handled on the receiving system’s side, through high-availability endpoints and validation methods in payloads. The webhook messages are not designed to follow multi-step authentication flows to get through a well-protected endpoint on the receiving system’s end, such as NetSuite’s RESTlets with JWT authentication. If they were to run such authentication flows, the execution of the internal workflows would be held up, and if it broke, error logging would be required. That defeats the entire purpose of quick notifications from the sending system’s side. (Security upon message dispatch is a topic, but rathermore via static signatures within the same message, for example via a static HMAC signature.)

Bla bla bla, so what? It means that going forward, NetSuite RESTlets are not a suitable way for integrations for transaction processing any longer. Most likely, your sending system such as Salesforce, Perk, Shopify, Magento, PayPal, Stripe, Checkout ,Revolut will not support it anyway. You will either need to deploy a hack via Suitelet GET endpoint (which wouldn’t be feasible for most of the systems mentioned above anyway) or you need to introduce a separate iPaaS solution, that publishes the endpoints, queues the messages, and then pushes them into Netsuite ERP.

In short, the announcements in the NetSuite Release Notes 2026.1 make an iPaaS solution with solid NetSuite integration a must-have for efficient integrations for transaction-processing. (Importantly, we are talking incoming transactions at high-frequency, not integration scenarios for reporting or filings to government authorities and the likes.)

Checking on our work with dozens of customers in the last two years, most NetSuite customers don’t have an iPaaS solution at hand, yet. Businesses are generally misinformed about why yet another system would be needed, now that they have purchased a powerful ERP platform such as NetSuite ERP (or SAP ERP Cloud, Sage Intacct, Salesforce, Hubspot, or Workday ERP for the matter). But strikingly, ERP core systems are not designed for real-time single-record integration posting, not even the frontrunner NetSuite ERP. Hence, the call for action is now. Those 12 or 24 months will pass quickly.