If you use Visual Studio Code and NetSuite-Sync and also have a Release Preview instance of NetSuite, you could fall down this same rabbit hole I just climbed out of. Beware!

Note: Here is my original article regarding VSCode & NetSuite-Sync

This morning, I made some changes to VSCode and noticed NetSuite-Sync was broken. So I quickly reinstalled. This has happened before and it only takes about 5 minutes to reinstall. However, it didn’t fix anything.

When you run the setup command, “ns -g”, to provide credentials to NetSuite-Sync, it creates a NetSuiteConfig.js file. During the prompts, you are asked to supply a role from a list of all your NetSuite roles across all instances of NetSuite, including your Release Preview. The role you select alters what you see below. This config file was used with a test instance of NetSuite which is long gone.

“account” : “[your account number]”,
“role”: “[gets the ID of the role you select]”,
“endpoint”: “[your account number]…”

Note: The account and endpoint now use the new datacenter agnostic versions. This example is old!

ns -g… If I selected my administrator role associated with our Release Preview instance of NetSuite, I’d get…

“account”: “[my account number]_RP“,
“role”: “3”,
“endpoint”: “[my account number]-rp…”

This worked. However, sandbox, which added _SB and -sb and my standard production Administrator role, which added no suffixes, both failed.

The only solution was to pick another role that was not an Administrator role. Only Administrator roles exist in our Release Preview copy of NetSuite. So a non-Admin role ended the confusion.

The problem was a routing issue on NetSuite’s side. I’m simply offering a workaround.