NetSuite TBA to OAuth 2.0: what the 2027.1 and 2028.2 changes mean

Two changes to NetSuite integrations are now on Oracle's published roadmap. From release 2027.1, you can't create new integrations that use token-based authentication (TBA). Then, in 2028.2, Oracle plans to remove SOAP web services completely.

If your NetSuite account talks to a bank, an e-commerce platform, a payroll system, a 3PL or an iPaaS such as Celigo or Dell Boomi, at least one of those connections is probably affected. This article sets out what's changing, why 2027.1 is the date that matters most, and a practical plan to move in good time.

What's changing, and when

These are the dates Oracle has published so far:

• 2025.2: the last planned SOAP web services endpoint.
• 2026.1: no new SOAP endpoints. OAuth 2.0 with REST is the recommended route for new integrations.
• 2027.1: no new integrations using TBA, whether for SOAP, REST web services or RESTlets. New integrations using the OAuth 2.0 authorisation code grant must also send PKCE parameters, and NLAuth authentication for RESTlets is switched off, with limited exceptions.
• 2027.2: the 2025.2 endpoint is the only SOAP endpoint still supported. Older endpoints keep running, but without fixes or support.
• 2028.2: SOAP web services are removed, and existing SOAP integrations stop working. Oracle has tentatively given the same release as the end of support for existing TBA integrations.

Release plans can change, so check Oracle's authentication release notes and SOAP removal FAQ before you finalise a plan.

Why 2027.1 is the date that matters

It's tempting to look at 2028.2 and decide there's plenty of time. Existing TBA integrations do keep working after 2027.1. But from that release, anything new has to use OAuth 2.0: a new integration record, a new connector, a new subsidiary or a new environment that needs fresh TBA credentials.

That catches more than people expect. Developers have pointed out that a refreshed sandbox may not be able to issue new TBA tokens, which would make testing old integrations after a refresh difficult. If you test in sandbox before every release, plan to have OAuth 2.0 working before 2027.1.

SOAP integrations need two changes, not one

OAuth 2.0 can't be used with SOAP web services. It works with REST web services, RESTlets and SuiteAnalytics Connect. That splits your integrations into two groups:

• Integrations on REST or RESTlets with TBA have the smaller job. The endpoints stay the same, and only the authentication changes.
• Integrations on SOAP need a new transport as well, usually REST web services and SuiteQL, or a RESTlet where REST doesn't cover what's needed. Payloads, field mappings and error handling all change, so treat these as small rebuilds and test them properly.

Until a SOAP integration is moved, switching it to the 2025.2 endpoint gives it the longest support window.

Which OAuth 2.0 flow to use

NetSuite offers two OAuth 2.0 flows, and the right one depends on how the integration runs:

• Client credentials (machine to machine): for server-to-server integrations with no user involved, such as nightly syncs, payment files and warehouse feeds. Authentication uses a certificate rather than a user signing in. You set it up under Setup > Integration > Manage Authentication > OAuth 2.0 Client Credentials (M2M) Setup.
• Authorisation code grant: for applications where a user signs in and approves access. From 2027.1, new integrations using this flow must use PKCE.

Most back-office finance integrations suit client credentials. Whichever you choose, give each integration its own role with only the permissions it needs.

A practical six-step plan

1. Take an inventory. List every integration record (Setup > Integration > Manage Integrations) and access token (Setup > Users/Roles > Access Tokens). The web services usage log (Setup > Integration > Web Services Usage Log) shows which integrations still call SOAP.
2. Rank by risk. Note what each integration does, who owns it and what breaks if it stops. Anything touching cash, payroll, tax or customer orders goes to the top.
3. Move SOAP integrations first. They need the most work, so start them early. Move any still on old endpoints to 2025.2 in the meantime.
4. Build OAuth 2.0 in sandbox. Create the new integration records and certificates, update the code or connector settings, and test end to end, including errors and retries.
5. Switch over in batches. Release a few integrations at a time, outside month-end, and keep the old credentials until each one is proven in production.
6. Retire what's left. Revoke old tokens, deactivate unused integration records and remove scripts nobody uses.

Third-party connectors need the same care. Ask each vendor, including your iPaaS, when their NetSuite connector supports OAuth 2.0 and what you need to do to switch.

A good moment to tidy up

An authentication project touches every integration, so it's a good time to deal with other technical debt at the same time: SuiteScript 1.0 RESTlets rewritten in SuiteScript 2.1, hard-coded IDs replaced with parameters, proper logging added and code moved into source control. Doing it in one planned project costs less than doing it twice.

It's also worth checking each release before it lands. A release readiness check tests your scripts and integrations in the release preview account before each upgrade, so 2027.1 doesn't come as a surprise.

Need help planning the move? The fixed-price SuiteScript 2.1 and OAuth 2.0 Upgrade starts with a free inventory of your scripts and integrations.