Guide to Using Token Based Authentication in NetSuite

11/22/2017

Last updated: 2026-05-29

Executive Summary:

Token Based Authentication (TBA) in NetSuite provides a secure, non-expiring method for connecting integrations via REST and SOAP web services, eliminating reliance on username and password credentials. This guide walks through the complete TBA setup process, from enabling the feature and creating integration records to generating tokens and testing connections. Techfino uses TBA across all production NetSuite integrations.

In this blog, I’ll walk you through setting up Token Based Authentication in NetSuite for integration via both web services options REST (Restlet) and SOAP (SuiteTalk). Token’s provide a secure authentication mechanism to connect to NetSuite without using the standard username and password and most importantly for integrations they do not expire when the credentials are changed or the password expires.

The first step in connecting to an integration is validating you are who you say you are. In NetSuite, a new authentication has come out for a more modern and security conscious way to do this. Historically NetSuite has required a user to specify their credentials in one manner or another using an ‘NLAuth’ scheme. This NLAuth is an implementation of the RFC 2617 standard and can be seen in NetSuite means of authorization for RESTlets uses.

Header: Value:

Authorization NLAuth nlauth_account=12345, nlauth_email=NotMyEmail@techfino.com, nlauth_signature=NotMyPassword, nlauth_role=3

The procedure is much the same for SuiteTalk web services using a passport in the header to perform validation inside the xml payload. An application id and other detail is required with web services as well

<passport>

<email> NotMyEmail@techfino.com <email>

<password> NotMyPassword <password>

<account> 12345 <account>

<role internalId="3" />

</passport>

In my experience working with scripting and integrations utilizing RESTlets and webservices, I’ve always desired a more elegant way to authenticate for NetSuite. Utilizing a header with an email and password included in the scheme is a bit…old school. Most modern authentications techniques are moving away from this.

The typical best practice using the legacy method is using a generic dedicated integration user with a generic company email and a strong secure password. If necessary, the password is stored encrypted on records / custom records with role restricted access.

Even using this methodology, there now exists a password which belongs to a non-human user but still needs to be maintained and should be changed periodically. Regardless, NetSuite will enforce changing the password periodically (default is 6 months) for users. NetSuite is also a bit cryptic when a password has expired. Below is the typical error I’ll get in emails from clients of ours asking why the integration isn’t working.

Bg Image

White paper

title-continuedsuccess-2

What if NetSuite support actually worked?

See the Continued Success difference.

Get the Whitepaper

{

"error":{

"code": "USER_ERROR",

"message": "Could not determine customer compid"

}

}

A little bit of digging into SuiteAnswers will yield the following explanation:

restlet resolve error message - could not resolve customer compid

The 2015.1 update brought a new authentication type, NetSuite started allowing token authorization for RESTlets and web services. In a nutshell, token authorization allows applications to interact on your behalf without using credentials. It is basically the Oauth 1.0 spec and fixes the above issues. Along with more elegance it offers numerous features/enhancements over the legacy authentication that make a great case for a switch.

  • No need to share and expose login information
  • No password that can expire. Tokens should be updated periodically but this is no longer driven by NetSuite.
  • Token Based Authentication can be implemented utilizing any 3rd party Oauth library
  • Tokens can be managed through the NetSuite API from RESTlets to add, update and remove access as necessary
  • Tokens are also SSO and 2FA compatible

The NLAuth scheme is a simple, quick authorization practice that can be setup and used easily but the advantages of token authentication greatly outweigh the additional upfront configuration. The best practices for the NLAuth scheme also require configuration and maintenance making it hard to make a case for legacy authentication moving forward.

To help with the process of learning how to setup and start using TBA, we have a guide below.

We created a full Token Based Authentication guide for practitioners to download and refer to when setting up Token Based Authentication for web services integration with step-by-step instructions along with sample code to test REST/SOAP endpoints. In the guide we walk you thru setting up Token Based Authentication, creating your token, and creating the Integration record needed for inbound integration via web services.

Then, we show a sample python program for invoking a RESTlet using Oauth TBA. Finally, we include a handy SuiteScript example that makes a SuiteTalk web service call to NetSuite to access Budgets, which are not exposed in the SuiteScript API.

We hope you find this information useful on your next Integration project! Please feel free to share your NetSuite integration tips and experiences.

Frequently Asked Questions About Token-Based Authentication in NetSuite

What is Token-Based Authentication (TBA) in NetSuite?

Token-Based Authentication (TBA) is a security mechanism that allows external applications to connect to NetSuite using access tokens instead of username and password credentials. It reduces the risk of credential exposure and is the recommended authentication method for all NetSuite REST and SOAP web service integrations.

Why should I use TBA instead of username/password in NetSuite integrations?

TBA is more secure than user credential-based authentication because tokens can be scoped to specific integrations, revoked independently, and do not expose user passwords. NetSuite has been phasing out username/password authentication for web services in favor of TBA to improve security across all integrations.

How do I set up Token-Based Authentication in NetSuite for REST (Restlet)?

To set up TBA for Restlets, you need to create an Integration Record in NetSuite, enable Token-Based Authentication, create an Access Token linked to a specific employee and role, and then use the generated token credentials in your OAuth 1.0 authorization headers when making REST API calls to NetSuite.

Does TBA work with SuiteTalk (SOAP) in NetSuite?

Yes. TBA is supported for both REST (Restlets) and SOAP (SuiteTalk) web services in NetSuite. The setup process is similar — you create an Integration Record and generate tokens — but the authentication headers differ slightly for SOAP requests.

What NetSuite permissions are required to set up Token-Based Authentication?

Setting up TBA requires Administrator access or a role with permissions including Access Tokens (full), Integration (view), and the ability to create employee access tokens. The integration record must also be configured to allow Token-Based Authentication before tokens can be generated.

Can I revoke or rotate NetSuite TBA tokens?

Yes. NetSuite allows administrators to revoke individual access tokens at any time without affecting other integrations. This makes TBA more flexible than shared credentials — if a token is compromised, it can be revoked and regenerated without changing login credentials used by other systems.

What should I do if my NetSuite TBA token stops working?

If a TBA token stops working in NetSuite, check whether the token was revoked, the associated user role was changed, or the integration record was deactivated. TBA tokens do not expire on their own but can be invalidated by role or access changes. Regenerating a new token pair and updating integration credentials resolves most authentication failures.

Talk to a NetSuite Expert

Tell us what you're working on, and we'll help you figure out the next step.