NetSuite OAuth 2.0 Mandate: What Breaks at Release 2027.1

03 Nov 2026

10 min

Automation

Implementation

Enterprise

Oracle has set a hard deadline for Token-Based Authentication (TBA) on NetSuite: starting with NetSuite release 2027.1, you will no longer be able to create new integrations that use TBA for SOAP, REST, or RESTlets. Existing TBA integrations keep running past that date, with full end of support tentatively planned for release 2028.2. If you build or maintain NetSuite connectors for clients, every new integration from 2027.1 onward has to start on OAuth 2.0.

This isn't a NetSuite feature announcement you can skim and file away. It changes how you store client credentials, how you request user consent, and how you handle token refresh for any NetSuite integration you stand up from here forward. Here's exactly what breaks, what doesn't, and how to build the OAuth 2.0 version instead of retrofitting a TBA integration later.

What is NetSuite actually deprecating at release 2027.1?

Three separate authentication changes land in the same release, and it's easy to conflate them. Oracle's authentication release notes list all three:

End of support for new TBA integrations. As of 2027.1, you can't create a new integration record that authenticates with TBA (consumer key/secret plus token ID/secret) for SOAP web services, REST web services, or RESTlets.
End of support for NLAuth. NLAuth, the older RESTlet authentication method that predates TBA, stops working entirely for all integrations, not just new ones.
PKCE becomes mandatory for the OAuth 2.0 authorization code grant. Any new integration using the authorization code flow must implement PKCE (Proof Key for Code Exchange) parameters.

None of this retires SOAP web services yet. That's a separate, later milestone: Oracle's SOAP removal is tracked for release 2028.2, the same release currently cited as the tentative end of TBA support for existing integrations.

Does my existing TBA integration break at 2027.1?

No. If you already have a working TBA integration, it keeps authenticating after 2027.1 ships. The 2027.1 change only blocks creating new integrations on TBA. The catch is the word "tentatively": Oracle's own end-of-support page for existing TBA integrations says that date is release 2028.2, not locked in. Plan the migration on your own timeline rather than waiting for a forced cutover notice, because a tentative date can move, and because you don't want twelve months of "we'll do it eventually" to collapse into a scramble once it's confirmed.

The integrations that break immediately at 2027.1 are any that use NLAuth for RESTlets. If a client's integration predates TBA and was never migrated, check for NLAuth now, not after the release ships.

What has to change if you're building a new NetSuite integration today

If a new NetSuite connector is on your roadmap for 2027 delivery, build it on OAuth 2.0 now. Three things change in practice:

1. Credential storage moves from a 5-part TBA secret to an OAuth 2.0 client

TBA integrations store five long-lived values: consumer key, consumer secret, token ID, token secret, and the account ID (realm). OAuth 2.0 replaces that with a client ID and client secret (or a signed certificate for machine-to-machine auth) tied to an integration record, plus short-lived tokens you request at runtime. If your credential vault was built around five static TBA fields per customer, you need a second schema for OAuth 2.0 clients, not a field rename.

2. Pick the right grant type for the integration pattern

NetSuite supports two OAuth 2.0 grant types that cover almost every integration shape:

Authorization code grant - a NetSuite user logs in and consents. Use this when the integration acts as a specific user with that user's role and permissions. Tokens from this flow are short-lived access tokens refreshed with a refresh token; third-party implementation guides document access tokens expiring in roughly 3,600 seconds (one hour), unverified past Oracle's own sample response, so build refresh into your client from day one rather than assuming a long-lived session.
Client credentials grant (machine-to-machine) - no human login step. This is the one most server-to-server NetSuite integrations should use going forward, and it is the direct OAuth 2.0 analog of what TBA was doing for unattended jobs.

The client credentials grant has a wrinkle worth knowing before you scope the work: NetSuite's client credentials flow authenticates with a signed JWT client assertion, not a plain client secret in the request body. Oracle's token endpoint documentation specifies that the client_assertion parameter is a JWT bearer token signed with the private half of a certificate that's mapped to the integration record in NetSuite. That means your migration has to generate and manage a key pair and upload the public certificate to NetSuite, not just swap one secret string for another. Budget for that when you estimate the work; it's a different credential-management shape than most teams expect from "OAuth 2.0."

text

POST https://<accountID>.suitetalk.api.netsuite.com/services/rest/auth/oauth2/v1/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<JWT signed with your private key>
&scope=rest_webservices

3. PKCE on the authorization code flow is no longer optional

If you're keeping the authorization code grant for user-context integrations, add PKCE now rather than after 2027.1 forces it. PKCE adds a code verifier and code challenge to the authorization request, closing an interception risk in the redirect step. Most modern OAuth 2.0 client libraries (and NetSuite's own SuiteCloud SDK) support PKCE out of the box, so this is largely a configuration flag, not new logic, but it has to be present in any integration record created from 2027.1 onward.

Migration checklist: moving an existing TBA integration to OAuth 2.0

You don't have to migrate a working TBA integration today, but if you're doing it proactively (recommended, given the tentative 2028.2 end-of-support date), the sequence looks like this:

Create a new integration record in NetSuite under Setup > Integration > Manage Integrations, with OAuth 2.0 enabled rather than Token-Based Authentication.
Choose the grant type that matches the integration's role. Server-to-server batch jobs and syncs should move to client credentials (M2M); anything that needs to act as a specific logged-in user stays on authorization code with PKCE.
Generate and register a certificate for the client credentials grant, or set up the redirect URI and consent screen for the authorization code grant.
Update your credential store and token refresh logic. OAuth 2.0 tokens are short-lived by design; your integration needs a refresh loop, not a one-time setup step like TBA's long-lived tokens allowed.
Run both integrations in parallel against a sandbox account before cutting production traffic over, since NetSuite does not retroactively convert a TBA integration record into an OAuth 2.0 one.
Decommission the TBA integration record only after the OAuth 2.0 version has handled a full production cycle (month-end close, batch exports, whatever the integration's heaviest load pattern is).

Where this breaks for ISVs and mid-sized enterprises specifically

If you're an ISV shipping a NetSuite connector to multiple customers, the certificate-based client credentials requirement is the detail that catches teams off guard: you now need a per-tenant key pair and certificate mapping workflow, not a single shared client secret. That's a real schema change to a multi-tenant credential vault, and it's worth scoping before a client asks why their 2027 renewal quote went up.

If you're a mid-sized enterprise with custom NetSuite modules feeding data to other systems (ERP-to-CRM syncs, custom approval workflows, reporting pipelines), the risk isn't the 2027.1 cutover itself, it's that your current TBA integration was built by someone who's no longer around, and nobody on the team knows which of the five TBA secrets maps to which NetSuite role. Audit what's running on TBA today before you need to migrate it under a deadline.

For teams also running NetSuite data into Docusign-driven approval or contract workflows, the authentication layer matters just as much on the Docusign side. fluidlabs has covered the broader NetSuite REST API integration patterns including SuiteQL and MCP access, and separately how NetSuite's AI connector opens banking data to MCP agents - both assume OAuth 2.0 as the baseline going forward, not TBA.

The full NetSuite authentication timeline through 2027.1

Release 2027.1 bundles more authentication changes than just TBA. Oracle's authentication release notes list a fourth change landing in the same release that's easy to miss if you're only tracking the OAuth 2.0 migration: two-factor authentication becomes required for all roles in NetSuite 2027.1, not just administrator roles. If any part of your integration setup relies on a service account logging in through a browser-based flow (common with the authorization code grant during initial consent), confirm that account's 2FA method is configured before the release ships, or the consent step will fail for reasons that have nothing to do with OAuth 2.0 itself.

Change	Effective release	Applies to
OAuth 2.0 recommended for new integrations	2026.1	All new REST integrations
No new TBA integrations (SOAP, REST, RESTlets)	2027.1	New integrations only
NLAuth authentication for RESTlets stops working	2027.1	All integrations using NLAuth
PKCE required for OAuth 2.0 authorization code grant	2027.1	New authorization code integrations
2FA required for all roles	2027.1	All NetSuite user roles
TBA end of support (existing integrations)	2028.2 (tentative)	All TBA integrations except SuiteAnalytics Connect
SOAP web services removed	2028.2 (tentative)	All SOAP-based integrations

Treat this as one coordinated authentication overhaul, not four unrelated line items. If you're scoping a migration project for a client, budget time for all five release-2027.1 items together, since several of them touch the same integration record and the same consent flow.

FAQ

Does NetSuite 2027.1 remove SOAP web services? No. SOAP web services removal is a separate, later milestone tracked for release 2028.2, the same release currently listed as the tentative end of support for existing TBA integrations.

Can I still use TBA for a new integration after 2027.1? No. From release 2027.1, NetSuite blocks creating new integration records that authenticate with TBA for SOAP, REST, or RESTlets. Existing TBA integrations keep working.

What's the difference between NetSuite's two OAuth 2.0 grant types? The authorization code grant requires a NetSuite user to log in and consent, and acts with that user's role and permissions. The client credentials (machine-to-machine) grant has no login step and authenticates with a JWT signed by a certificate registered to the integration record, making it the closer match for unattended, server-to-server jobs that TBA used to handle.

Do I need a certificate for every NetSuite OAuth 2.0 integration? Only for the client credentials grant. The authorization code grant uses a client ID, client secret, and a browser-based consent step instead.

Next step

If you're scoping a NetSuite integration for a 2027 delivery, or auditing what's quietly still running on TBA, fluidlabs builds and runs custom NetSuite integrations for ISVs and mid-sized enterprises connecting NetSuite to the rest of their stack. Talk to the team about migrating your NetSuite authentication before the deadline becomes an emergency.