NetSuite’s planned updates for web services SuiteTalk web services - part II

In their 2026.1 Release Upgrade Notes, Oracle NetSuite has announced major changes to the roadmap of their powerful SuiteTalk web services, a key unique selling point to NetSuite and driver for its public cloud SaaS strategy of 30 years, which has become a standard for enterprise software since. (It’s actually remarkable how NetSuite and the SuiteTalk platform have co-shaped the SaaS business.)

For all the changes and the recommended actions, read our previous article here: https://www.acunomic.com/post/netsuite-s-planned-updates-for-web-services-will-probably-affect-or-break-almost-all-of-your-netsu

• The changes are all the more remarkable as they mark a major turn from seemingly iron concepts about NetSuite integration architecture:

  • Authentication:

    In terms of authentication, about 10 years ago at Oracle, product and development teams themselves remained sceptical about adopting OAuth 2.0 authentication flows for system integrations in the first place. OAuth 2.0 was considered an inadequate authentication protocol for machine-to-machine (server-to-server) integrations. Indeed, core developers in the original team criticised and forsook their own work on OAuth 2.0 as “Road to Hell”. (OA

    

    uth 2.0 and the "Road to Hell")

    But when OAuth 2.0 consortium-leaders such as Microsoft limited web service authentications to User Credentials and OAuth 2.0 credentials early on (infamously with the native connectors of Microsoft Power BI), pressure on Oracle Netsuite’s dev teams swiftly increased. Pushbacks continued into the late 2010s. (We had quite a few discussions with Oracle over enhancement requests ourselves, something we are actually grateful of as Netsuite clearly engaged in these discussions.)

    With Release Upgrade 2020.1, OAuth 2.0 was subsequently introduced. However, the authentication flow via Authorization Code Grant with Redirect URI, as well as the initial manual Refresh Tokens, left OAuth 2.0 as a suboptimal alternative for machine-to-machine integrations. In fact, up until three to four years back, NetSuite continued to recommend token-based authentication - true to the spirit of the machine-to-machine centric OAuth 1.0 protocol.

    Accordingly, Netsuite partner integrations focused on the tried and proven OAuth 1.0-based token-based authentication flow - both amongst business software suppliers, i.e. those other SaaS solutions you are using, as well as integration software (iPaaS) providers. Token-based authentication is/was likewise the golden standard amongst Netsuite implementation and integration partners - although a remarkable number of them continued with User Credentials-based integrations. More about User Credentials at the end of this article.

  • Integration protocols:

    In terms of web service architecture, NetSuite recommended SOAP web services for standardised endpoints and RESTlet web services for custom executions until a few years back. (Think of RESTlets like microservices executed on the back of web service endpoints: RESTlets allow executing multiple tasks in a single web service request and then, also returning bespoke data and error messages in the web service response to your external system. Say, you want to record a new event or sales order in NetSuite and create the customer or contact record(s) along the way, but only if said master data would be new to NetSuite, then RESTlets allow you to do all that in a single web service request. Such a microservice approach reduces the number of integration calls, ensures no broken or fragmented integration calls, where you create only parts of the data, and reduces the logic on the sender side, because the Netsuite-specific logic is running within Netsuite. In short, you send your data to NetSuite and the RESTlet scripts do the thinking.)

    It was only in Release Upgrade 2020.1, when the new REST(ful) API according to the Open API standard was released for general availability. That’s about 5 years ago. The new API was and remains a marvel, featuring not only comprehensive and up-to-date coverage of NetSuite business objects for CRUD operations, but also methods for workflow executions (actions) and SQL queries (searches) via SuiteQL. Furthermore, schemas for all business objects on respective methods can be loaded. (We only know of Odoo featuring a similarly comprehensive functionality built directly into the REST API framework as of the time of this writing.) Yet, despite the power and comprehensiveness of the new API, the new REST(ful) API seemed to live a shadow live: It was seldomly mentioned amongst SuiteApp integrations and discussed in custom integrations. Expection applied to iPaaS providers, especially new upstart players and large behemoths not close to the RESTlet framework up to that point, to whom the REST(ful) API opened doors for a well-acquainted integration approach. Strikingly, rumour has it that the REST(ful) web services were implemented in such a comprehensive and also speedy matter for integrating Oracle Netsuite into the Oracle Integration Cloud and Data Warehouse offerings. Albeit, adopting the new API framework was seldomly advertised amongst any of the iPaaS providers. Surprisingly, Oracle does not advertise their Oracle Integration Cloud for Netsuite integrations as much as other services in the Oracle application portfolio, for example, PBCS (first addition to the Netsuite product pricelist), Netsuite Data Warehouse, or Oracle CPQ (originally Verenia). In fact, when NetSuite announced the acquisition of the eCommerce integration FarApp and released it as NetSuite Connector in the later 2021.2 Release Upgrade, the product strategy seemed to go counter the REST(ful) API web services and Oracle Integration Cloud as a comprehensive integration suite.

    For all these reasons, SOAP and RESTlets stayed firmly in the saddle throughout the last 5 years.

  • 
    

  Given this history, the announcements practically mark a 180° turn from practices just about 10 years ago and a timeline of 2 years for the full uturn is relatively short.

  Whilst the new focus on a REST(ful) API according to the Open API 3.0 standard will resonate with established integration methods in the public cloud and SaaS ecosphere, the decision on authentication flow is more nuanced: Yes, OAuth 2.0 has become the de facto best-practice authentication protocol and grant type via client credentials the go-to authentication method. (Ironically or perhaps most strikingly, grant type via client credentials is closest to the old OAuth 1.0 machine-to-machine standard giving ample credit to Oracle’s initial argument.)

  Importantly, however, on the point of client credentials grant type, Oracle decided to opt for a format called JSON Web Token (JWT) rather than bearer token or any other opaque token.

  The decision for JWT endorses best practices for integration security in machine-to-machine integrations as of 2026, but it also makes authentication quite a bit more complex. In fact, most SaaS solutions and even quite a few iPaaS solutions do not support JWT grant flows out of the box!

  This puts all NetSuite customers in a conundrum on how to respond to the 2026.1 Release Upgrade announcement on authentication: Do we want to prepare best for the future, or wiggle through with Token-based Authentication still? (As an integration partner with experience of more than a dozen years, our recommendation is clear.)

  The decision for JWT is reminiscent to the introduction of TBA (Token-based Authentication) and phase-out of authentication via User Credentials (yes, a user’s email and password) about 7 years back. The announcement that NetSuite would no longer accept machine-to-machine integrations via the clearly insecure User Credentials authentication caught a larger number of NetSuite partners off guard. Even more, some partners and a large iPaaS software provider (who shall not be named here) gambled on leveraging their customer base and pushed for the retention of authentication via User Credentials. Oracle NetSuite gave them one more year as an exception and pushed through the decision anyway.

  Doubts may arise whether Oracle will really follow through with a roadmap of such fundamental, strict, and relatively rapid change to their integration protocols. Arguments may refer to the complexity with JWT grants or large and vested partners with their large customer base. But then again, the decisions adopt de facto standards in public cloud integrations and best practices in integration security protocols as of beginning of 2026. In terms of the timeframe of 12 to 24 months, Oracle Netsuite is actually accommodating compared to other software providers. Take Shopify for example, which releases new REST Open API specifications thrice a year and regularly phases out old REST protocols on a two year basis. The introduction of GraphQL and its instructions for adoption for integration partners with significant customer base was also swift and rigoruous. Meanwhile, 30 years old Oracle Netsuite has been offering the same SOAP and RESTlet technology up until now and is still in version 2(.1) of its SuiteScript language. It’s time for a change. And this change will be to the benefit of customers.