API tokens are one of the most powerful ways to connect external applications and services to NetSuite. They provide programmatic access can match, or even exceed, the capabilities available through a standard user who accesses NetSuite through the user interface. Because of this, tokens should be treated as high-value credentials. Compliance standards such as ISO 27001 and NIST 800-53 highlight the requirement to protect, rotate, and manage authentication secrets, and API tokens fall directly into this category. In short, they must be well governed and controlled.
In NetSuite, tokens are generated by navigating to Setup → Users/Roles → Access Tokens → New. During creation, you assign the integration (application name), user, role, and token name. A key detail worth noting is that the Token ID and Token Secret are only displayed on the initial setup page at the point of generation—NetSuite does not allow you to return later and view it again. This design helps reduce token exposure, but it also means organizations need a secure storage strategy from the outset. The best practice is to vault tokens in systems ensuring they never sit unencrypted in scripts, configuration files, or developer workstations.
Security does not stop at generation. Tokens should always be scoped as narrowly as possible. Assign them only to the integration role they truly need and restrict access to the specific REST or SOAP services or datasets required. Organizations should also set expiration rules—ideally limiting tokens to short lifetimes, such as 90 days—so they are forced to be reviewed and renewed. NetSuite Password rotation policies set in the General Preferences page don’t apply to tokens and therefore, would have to be a manual process. NetSuite administrators can take this a step further by disabling or revoking tokens that have not been used within a defined timeframe, reducing the attack surface of forgotten credentials.
To make management and auditing easier, tokens should follow a clear naming convention. A recommended format is INTG_<ApplicationName>_<Environment>, such as INTG_WD_PROD for a Workday production integration. Alongside the name, administrators should document the token’s owner, intended purpose, and expiration date, creating a reliable map between tokens in NetSuite and the systems or teams using them. Detailed documentation can be helpful when responding to audit requests or investigating incidents.
| Token Name | Owner | Purpose | Expiry Date |
| INTG_SFDC_PROD | John Smith | Salesforce integration (Prod) | 12/31/2025 |
| INTG_BILLPAY_TEST | Maria Lopez | Bill.com sandbox testing | 03/15/2026 |
| INTG_DATAWH_PROD | IT Data Services | Data warehouse nightly sync | 11/01/2025 |
Visibility is another cornerstone of good token security. NetSuite’s audit logs provide details about who created a token and when it was created. Forwarding these logs to a SIEM allows organizations to set up proactive monitoring, for example, generating alerts if a token is created outside of an approved change window. If your organization does not have a SIEM system, periodic monitoring is a great alternative. These audit capabilities transform tokens from potential blind spots into transparent, well-tracked credentials.
Finally, organizations should treat token governance as an ongoing process rather than a one-time setup. Because tokens act as privileged authentication credentials, they should be subject to lifecycle controls: secure vaulting, periodic rotation, and periodic reviews. By embedding these practices, businesses ensure that their API tokens remain an enabler of secure integrations, not a lingering risk.