NetSuite 2027.1: What the Authentication and SOAP Changes Mean for Your Shopify Integration

01Overview of NetSuite 2027.1 Changes

NetSuite 2027.1 changes four things: NLAuth authentication, Token-Based Authentication (TBA), the OAuth 2.0 authorization code grant flow, and SOAP web services. Not every Shopify-NetSuite integration touches all four; a given integration's actual exposure depends on which authentication method and API protocol it currently runs on. The sections below work through each one, NLAuth, TBA, OAuth 2.0 with PKCE, and SOAP, so a business can match its own integration against the specific change that applies to it rather than treating this as one uniform deadline.

NLAuth is retired for RESTlet and API authentication in 2027.1. An integration still authenticating with NLAuth, meaning it logs in using an account, email, and password rather than a token or an OAuth flow, stops working at that release. Unlike the changes to TBA and SOAP described below, this is not limited to newly created integrations: an integration that has been running fine for years stops authenticating the moment 2027.1 ships if it is still using NLAuth for its ongoing calls. Oracle documents one narrow exception: existing integrations that call the IssueToken endpoint, the NLAuth-authenticated call used to issue a TBA token, are excluded from this end of support and keep working.

Token-Based Authentication (TBA) is restricted, not retired outright: new integrations using TBA for SOAP web services, REST web services, and RESTlets are blocked starting with 2027.1, but existing TBA integrations keep working until their tentative retirement in the 2028.1 release. That gives an integration already running on TBA a real, if not unlimited, window to migrate.

NetSuite 2027.1 also requires Proof Key for Code Exchange (PKCE) for any new integration using the OAuth 2.0 Authorization Code Grant Flow, for both public and confidential clients. PKCE was previously optional for confidential clients and required only for public ones.

SOAP web services run on their own separate timeline: the 2025.2 release is the last planned SOAP endpoint, no new SOAP endpoints are issued after the 2026.1 release, and SOAP is fully retired at the 2028.2 release.

02Impact of Authentication Method Changes

The authentication method a Shopify-NetSuite integration uses determines whether the 2027.1 changes affect it at all. NetSuite 2027.1 changes what authentication protocols new and existing integrations may use, but only an integration still on NLAuth, TBA, or SOAP is actually exposed. Understanding which of these methods an integration currently relies on is the first step in assessing that exposure.

Authentication methods control which systems and users can read or write data between Shopify and NetSuite. Under 2027.1, an integration still relying on NLAuth or TBA has to move to OAuth 2.0, which now requires PKCE as part of the authorization code grant flow rather than treating it as optional.

An integration still on NLAuth stops working at 2027.1 with no transition period to plan around, aside from the narrow IssueToken exception described above. An integration on TBA has more room: existing TBA integrations keep working until the tentative 2028.1 end of support, but any new integration built on TBA from 2027.1 onward is blocked outright, so new development already has to target OAuth 2.0.

Once a deadline passes, the effect is functional rather than abstract: requests using a blocked authentication method are rejected the same way any invalid-credentials request would be. That is what makes checking which method an integration currently uses worth doing before the deadline, not after data stops syncing.

The practical takeaway carries through the rest of this article: what matters is the specific authentication method in use, not the platform pairing itself. An integration already on OAuth 2.0 has little to do here; one still on NLAuth, TBA, or SOAP has real, dated work ahead of it.

03Identifying Your Integration's Authentication Method

Which of NLAuth, TBA, or OAuth 2.0 a Shopify-NetSuite integration actually runs on is not always obvious from the outside, since it has to be checked directly in NetSuite. This section walks through where to look and how to tell the three apart.

Checking Integration Record Configuration

The first step in identifying your integration's authentication method is to examine the integration record configuration within NetSuite. Start by logging into your NetSuite account with administrative privileges. Navigate to Setup > Integration > Manage Integrations. This will display a list of all existing integrations within your environment.

Click on the specific integration you wish to investigate. The integration record shows which authentication options are enabled for it, typically labeled "Token-Based Authentication" and "OAuth 2.0." The record does not store the actual credentials themselves: TBA's Token ID and Token Secret are generated separately, and OAuth 2.0's Client ID and Client Secret are generated when the integration record is first saved.

Steps to Verify Authentication Method

Once you locate the authentication settings, verify the method by checking for specific indicators:

1. Token-Based Authentication (TBA): the integration record shows "Token-Based Authentication" enabled. The actual Token ID and Token Secret are generated under Setup > Users/Roles > Access Tokens, not inside the integration record itself. Existing TBA integrations keep working until the tentative 2028.1 end of support; no new TBA integration can be created from 2027.1 onward.

2. OAuth 2.0: the integration record shows "OAuth 2.0" enabled, along with a redirect URI. NetSuite generates the Client ID and Client Secret (as the Consumer Key and Consumer Secret) when the record is saved. A new OAuth 2.0 integration using the authorization code grant flow must also use PKCE as of 2027.1.

3. NLAuth (being retired): NLAuth does not appear as a distinct option inside the integration record. It shows up in the RESTlet or script code itself, typically as a login call using an account, email, and password rather than a token or an OAuth flow. If that pattern appears anywhere in the integration's code or configuration, treat it as NLAuth and prioritize it, since it stops working at 2027.1 for existing integrations as well as new ones, apart from the documented IssueToken exception covered above.

Risks of Misidentification

Misidentifying the authentication method has a concrete failure mode: if an integration is assumed to be using OAuth 2.0 when it actually uses NLAuth, it simply stops authenticating once 2027.1 arrives, with no warning beyond that failure itself.

The reliable fix is checking every integration record directly, particularly ones that have not been touched recently, rather than assuming based on when or how the integration was originally built.

04Integration Architecture Patterns for Shopify-NetSuite

Shopify-NetSuite integrations are typically built one of three ways: native/prebuilt connectors, Integration Platform as a Service (iPaaS) platforms, or custom-built integrations. Each can be running any of the authentication methods above, so the architecture type alone does not indicate exposure; only checking the specific integration does.

For the fuller picture of how these three architectures actually get chosen and built, NewMotion's guide to Shopify-NetSuite integration covers that decision in depth. This article stays focused specifically on the 2027.1 authentication and protocol changes and how they apply to whichever architecture is already in place.

Native or prebuilt connectors are built specifically to link Shopify and NetSuite, usually supplied directly by one of the platforms or by a third-party vendor. They are easy to set up, but a connector that has not been updated to the current NetSuite standards can still be running NLAuth or TBA under the hood. Checking whether a given connector already uses OAuth 2.0 with PKCE is the only way to know its real status ahead of 2027.1.

iPaaS platforms, such as MuleSoft or Dell Boomi, connect Shopify, NetSuite, and other applications through a shared middleware layer. These platforms often support modern authentication methods, but a specific integration built on one of them can still be running a legacy method if it was set up before the 2027.1 changes were announced. Confirming that a given integration already uses OAuth 2.0 directly is safer than assuming it does because the platform itself is modern.

Custom-built integrations are the most flexible, built to whatever the business's own requirements were at the time. That same flexibility means they are also the most likely to still be running NLAuth or TBA if nobody has revisited the authentication layer since it was first built. Auditing these directly is the only reliable way to find out.

None of these three architectures is automatically safe or automatically exposed. A native connector, an iPaaS platform, and a custom-built integration can each already be running OAuth 2.0, or each still be running NLAuth or TBA from years ago. The only way to know is to check the specific integration, not to assume based on which category it falls into.

05Migration from TBA and NLAuth to OAuth 2.0

With the NetSuite 2027.1 release, businesses running NLAuth or TBA on their Shopify-NetSuite integration need a plan to move to OAuth 2.0. NLAuth stops working at 2027.1, apart from the narrow IssueToken exception described above. TBA-based integrations keep functioning, but no new TBA integration can be built from 2027.1 onward, and existing TBA integrations are tentatively scheduled to stop working at 2028.1.

Migration Process Overview

Migrating to OAuth 2.0 starts with confirming which integrations actually need to move: those still on NLAuth first, given the immediate cutoff, then those on TBA. The overall sequence is the same for both: select the right OAuth 2.0 flow, generate new credentials, update the integration record, and retire the old credentials only after the new ones are confirmed working.

Steps for Migration

Evaluate current integrations. Identify every integration still using TBA or NLAuth by reviewing integration records in NetSuite, since this is where enabled authentication options are visible.

Choose the OAuth 2.0 flow. For most integrations, the authorization code grant flow with PKCE is the right choice, since PKCE is now required for any new integration built on this flow.

Generate new credentials. Saving the integration record with OAuth 2.0 enabled generates a Client ID and Client Secret; these replace whatever TBA token or NLAuth login was used before.

Update the integration configuration. Point the client application at the new OAuth 2.0 credentials and confirm it can complete the token exchange before touching production traffic.

Adjust API calls where needed. Requests need to carry the new OAuth 2.0 access token, and any code that assumed a TBA token or NLAuth login has to be updated accordingly.

The main risk during this work is downtime or a break in data flow if the cutover isn't sequenced carefully. Testing the migrated authentication against real transaction flows, covered in the next section, is what actually confirms the migration worked, not just that new credentials were generated.

Some businesses handle this migration internally; for an integration with enough custom-built history that the scoping itself is nontrivial, getting the migration scoped and built is often the faster path to a tested, working result.

06Migrating from SOAP to REST Web Services

SOAP and REST are different protocols, so migrating means re-implementing each integration point rather than changing a setting. This section covers mapping SOAP operations to their REST equivalents, updating API calls, and handling the data-format change from XML to JSON.

Migration Process Overview

Start by identifying every SOAP-based interaction between Shopify and NetSuite: which API calls exist and what data structures they use. That inventory is what gets mapped to REST equivalents in the next step, not a starting guess.

NetSuite's REST web services use standard HTTP methods, GET, POST, PUT, and DELETE, in place of SOAP's more rigid operation-based structure, and exchange data as JSON rather than XML, which is a lighter payload format.

Necessary API Call Updates

Each SOAP operation has to be translated into its REST equivalent individually: a SOAP call that retrieved customer data, for example, maps to a REST GET request against the corresponding endpoint, with a different URL structure and payload shape. Authentication headers on the REST calls need the same attention, since they carry the OAuth 2.0 access token rather than whatever SOAP's authentication used.

Technical Details of API Changes

REST's stateless model is the main structural difference from SOAP: each request has to carry all the information the server needs on its own, rather than relying on state from a prior call. A SOAP operation that took several inputs on one call sometimes maps to a single, simpler REST endpoint, but that has to be confirmed per operation rather than assumed.

Handling Data Mapping

Data mapping is the other real risk point: SOAP's XML schemas have to be translated into JSON without losing fields in the process. Automated conversion tools can do the first pass, but manual verification against the original schema is what actually catches a dropped or mismapped field.

Risks and Failure Modes

The main risk is a REST endpoint that does not fully replicate what the SOAP service it replaces actually did, which shows up as data inconsistencies rather than an obvious error. Testing each migrated endpoint against its original SOAP behavior, not just confirming it returns a response, is what catches this before it reaches production data.

Migrating from SOAP to REST is real engineering work: mapping SOAP operations to REST endpoints, updating API calls, and getting the data mapping right so nothing is lost converting from XML to JSON. Getting it right the first time depends more on thorough testing than on the migration itself being complicated.

07Testing and Validation Post-Migration

Testing after migration confirms two separate things: that the new authentication actually works, and that the transaction flows running through it still behave the same way they did before. Skipping this step means the first sign of a problem is a real order or inventory update failing silently.

Testing does two things here. It confirms the integration authenticates correctly against NetSuite using OAuth 2.0, and it confirms the credential change did not break anything downstream. An OAuth 2.0 token that is not correctly attached to API calls, for example, shows up as a failure to retrieve or send data, which then affects order processing and inventory.

End-to-end validation covers the actual transaction flows: order creation, inventory updates, and customer data sync, each tested under real conditions rather than assumed to work because authentication succeeded. Creating a test order in Shopify and confirming it appears correctly in NetSuite is a direct check; a discrepancy there points back to the authentication change rather than somewhere else in the integration.

Specific transaction flows to validate include:

Order creation and fulfillment. Confirm that orders placed in Shopify are correctly created in NetSuite and that fulfillment processes are initiated as expected.

Inventory updates. Confirm that inventory-level changes in NetSuite are accurately reflected in Shopify, preventing overselling or stock discrepancies.

Customer data synchronization. Confirm that customer record updates in one system reflect correctly in the other.

Refund and return handling. Confirm that refunds processed in Shopify trigger the correct updates in NetSuite and that financial records stay accurate.

These four checks matter because they are the same order, inventory, and fulfillment flows that the rest of a Shopify-NetSuite integration, and any broader ecommerce automation work built around it, depends on staying accurate.

Skipping this step means the real verification happens in production instead: the next order, inventory sync, or refund becomes the test, with no chance to catch a problem before it is already affecting live data.

08Consequences of Ignoring Migration

For an integration still on NLAuth specifically, other than the narrow IssueToken exception described earlier, there is no partial state: the moment 2027.1 takes effect, the login calls it depends on stop authenticating, and the integration stops moving data between Shopify and NetSuite entirely.

TBA is different: an existing TBA integration keeps functioning past 2027.1, tentatively until 2028.1. What is blocked immediately is building any new integration on TBA; any new development has to target OAuth 2.0 instead.

SOAP runs on its own separate timeline from NLAuth and TBA: the 2025.2 endpoint is the last one issued, it is the only supported version from 2027.1 onward, and SOAP is fully retired at 2028.2.

The practical difference between planning this work in advance and reacting to it later is mostly about sequencing: a migration scoped ahead of time can be tested against real transaction flows before cutover, while one done after an integration has already stopped authenticating has to happen live.

Planning the migration to OAuth 2.0 ahead of these deadlines, rather than during the week they land, is what keeps the cutover a scheduled piece of work instead of a scramble.

09Practical Next Steps for Businesses

Once a business has identified which authentication method its Shopify-NetSuite integration actually uses, the next step is sequencing the work, not guessing at it. Start from the audit results: does the integration use NLAuth, TBA, or OAuth 2.0, and does it call SOAP, REST, or RESTlet endpoints. That answer determines both whether any action is needed and how much time is realistically available.

Prioritize by actual urgency rather than treating every deprecated method the same way. An integration still authenticating with NLAuth needs attention first: that method stops working at 2027.1, for existing integrations as well as new ones, apart from the narrow IssueToken exception described earlier. An integration on TBA has more runway, since 2027.1 only blocks building new TBA-based integrations; existing TBA integrations keep functioning until the tentative 2028.1 end of support. An integration still calling SOAP web services falls somewhere in between: no new SOAP integrations can be built from 2027.1 onward, but existing SOAP integrations continue to work until the 2028.2 removal date.

From there, scope the migration as its own defined piece of work rather than something to figure out during a deadline week. That means identifying which integration records need updated credentials, which API calls change if SOAP is involved, who is responsible for testing the migrated authentication against real transaction flows, and what a realistic cutover window looks like given how the integration was originally built. A native connector, a middleware platform, and a custom-built integration each carry a different amount of this work, which is why the scoping step comes before any commitment to a timeline.

The practical risk of doing nothing is not the same for every business, because it depends on which of these authentication methods and protocols the specific integration actually uses. Waiting without checking is a bet that the exposure is lower than it actually is. Confirming it directly, through the audit already described, is a smaller amount of work than finding out the hard way when authentication fails.

10Conclusion

NetSuite 2027.1 does not affect every Shopify-NetSuite integration the same way. Whether it matters to a specific business comes down to one question: which authentication method and protocol that integration currently uses. An integration already running on OAuth 2.0 and REST web services has little to do here. An integration still authenticating with NLAuth is on the shortest timeline of the three, since that method stops working at 2027.1 outside the narrow IssueToken exception covered earlier. An integration on TBA or SOAP has more room, but not unlimited room, given the tentative 2028.1 end of support for TBA and the confirmed 2028.2 removal of SOAP.

The audit described earlier in this article, checking which authentication method and which API protocol a Shopify-NetSuite integration actually uses, is the starting point for answering that question with a real answer instead of a guess. From there, the migration work itself, updating credentials, moving from SOAP to REST where needed, adopting OAuth 2.0 with PKCE, and testing the migrated integration against real order, inventory, and pricing flows, is a scoped, known piece of engineering work rather than an open-ended one.

Confirming exposure now, while there is still time to plan the work deliberately, is simpler than doing it after authentication has already stopped.