The quick answer
Enter your account ID on the vendor's NetSuite OAuth page, then download its script and unzip it. In NetSuite, turn on the SuiteCloud features the vendor lists, upload the .js file with Company-wide Usage ticked, create a RESTlet script record with Save and Deploy, set the deployment Status to Released and choose its audience. Copy the deployment's External URL, paste it on the vendor's page and click Save. Each user then authorizes from the add-in.
The example is a finance team at Fernwood Outfitters Ltd. connecting the Coefficient add-in for Google Sheets or Excel to NetSuite. Ingrid Vandersloot, a NetSuite administrator, does the setup. The company, people, account ID and script numbers are fictional example data.
Before you start
You need a role that can enable features, add files to the File Cabinet and create scripts, such as Administrator. The vendor's page calls this a one-time configuration for the whole account, so other users do not repeat it. They authorize their own connection later from the add-in.
Three things in this setup belong to the vendor, not to NetSuite:
- The vendor's page and script. The screenshots of the vendor's page are a reconstruction, not a live capture, so its wording, layout and menu path to the page may differ from what you see today. Follow the vendor's current page and its written instructions where they differ from this article.
- The script package. The walkthrough uploads one .js file. Open the .zip and check what it contains. If the script loads other files, upload those too. Read the script as you would any third-party code that is about to run in your account, and try it in a sandbox first if you have one.
- The OAuth 2.0 client details. Some vendors ask you to register an integration record under Setup > Integration > Manage Integrations, with a redirect address, or to add other values on their page. The walkthrough does not show this step, so follow the vendor's instructions for it.
The NetSuite screens were observed in one account and release, so check the labels against your own. Saving the External URL does not prove that anyone can connect. The last section covers the test.
01. Enter the account ID on the vendor's page
Open the vendor's NetSuite OAuth page from the add-in. It lists four steps. In step 1, Enter your account ID, type the account ID 6174382 and click Next. The vendor's hint says to read the ID from your browser's address bar, the part before .app.netsuite.com. The example address under the box is the vendor's placeholder, not your ID.
If you are not sure of the ID, confirm it in NetSuite under Setup > Company > Company Information. Sandbox accounts use a different form, for example 1234567-sb1 in the address and 1234567_SB1 as an account ID. Use whichever form the vendor asks for and do not convert it by hand.
02. Download and unzip the connector script
Step 1 now shows a check mark and step 2, Download zip file with script (.js), opens. Click Download (.zip) and unzip the file so that you have the .js script. Tick I have unzipped the .zip file and click Next.
Step 3, Configure in NetSuite, opens with Open Configuration Steps and an I have configured in NetSuite box. Leave the vendor's page open and continue in NetSuite.
03. Enable the SuiteCloud features
In NetSuite go to Setup > Company > Enable Features and open the SuiteCloud subtab. The walkthrough follows the vendor's list and ticks these:
- SuiteScript: Client SuiteScript, Server SuiteScript and SuiteScript Server Pages.
- SuiteTalk (Web Services): SOAP Web Services and REST Web Services.
- Manage Authentication: SuiteSignOn and OAuth 2.0.
Click Save. NetSuite returns to Setup with the features enabled.
Not everything on that list is inherent to a RESTlet reached through OAuth 2.0. Server SuiteScript, REST Web Services and OAuth 2.0 are the normal account-level requirements. The rest are on the list because of how this vendor's package is built. Enable what the vendor's current instructions say, and ask the vendor before you leave any of them off. Token-based Authentication is a separate method for OAuth 1.0 connections. It is already ticked in this sample and the walkthrough does not change it.
04. Upload the script file for company-wide use
Go to Customization > Scripting > Scripts > New. This opens Upload Script File, which takes a file that is already in the File Cabinet. Click the plus icon beside Script File to add one without leaving the page.
In the File window the walkthrough enters the File Name spreadsheet_connector_restlet.js, keeps the Folder SuiteScripts, ticks Company-wide Usage and clicks Save. On a real computer, Select File opens your computer's file chooser, which the walkthrough does not show. Choose the .js file from the unzipped folder, not the .zip.
Company-wide Usage makes the file available throughout the account, not only to its owner, so a deployed script can load it when it runs for other users. It is a file setting. It grants no record permissions and does not let anyone call the RESTlet. If the script loads other files, make those available the same way.
The window closes and Script File shows spreadsheet_connector_restlet.js.
05. Create the RESTlet script record and deploy it
Click Create Script Record. NetSuite reads the script type from the file, and the new Script form shows Type RESTlet. Enter the Name Spreadsheet Connector RESTlet, open the Save menu and click Save and Deploy. This saves the script record and opens a new deployment form for it. NetSuite can fill in the deployment title from the script name, but the deployment still needs its own status and audience.
06. Release the deployment and set its audience
The Script Deployment opens with the Title Spreadsheet Connector RESTlet and Status Testing. A Testing deployment is meant for testing, not for normal use, so change Status to Released and keep Deployed ticked.
Leave Log Level at Debug while you set the connection up. Debug is the most detailed level and can store a lot of data in the Execution Log. Once the connection works, move to a quieter level such as Audit or Error.
Open the Audience subtab and tick Select All above Internal Roles and Select All above Employees, then click Save. That is the simplest setting, and it is the widest. The audience decides who may call the deployment. It does not grant record permissions, so the role a user authorizes with still needs its own permissions, including those for OAuth 2.0 logins and REST Web Services.
In production, consider a narrower audience instead. Create a role with only the permissions the connector needs, assign it to the people who will connect, select that role and those employees, and test with a user who is not an administrator.
07. Copy the External URL
The saved deployment lists two addresses. URL is the relative path used inside NetSuite. External URL is the full address on the account's restlets.api.netsuite.com domain, which is the one the connector needs. Copy the External URL, which in this example ends in script=2204&deploy=1. Copy the generated value instead of building it yourself, because the script and deployment numbers are different in every account.
The enlarged screenshot also shows a sample ID, customdeploy2205, that does not match the deploy=1 in the URL. That mismatch is an artifact of the sample data. In your account, use the External URL exactly as NetSuite shows it and do not work it out from the ID.
08. Save the External URL on the vendor's page
Return to the vendor's page, tick I have configured in NetSuite and click Next. In step 4, Provide the external URL, paste the External URL and click Save.
The page shows a Saved successfully notice. Close it. The page now reads NetSuite OAuth has been configured and lists the account ID 6174382 under Accounts.
Check the result
- The SuiteCloud features from step 3 are enabled on Setup > Company > Enable Features.
- The script file is in the SuiteScripts folder with Company-wide Usage ticked, and the script record has Type RESTlet.
- The deployment shows Status Released and Deployed ticked, and its audience matches who should connect.
- The External URL you saved is on the
restlets.api.netsuite.comdomain and ends in the script and deployment numbers NetSuite generated. - The vendor's page showed Saved successfully and now lists your account ID under Accounts.
Saving the URL does not prove that a user can connect. Test it as an ordinary user: connect from the add-in's sidebar, click Authorize and confirm that NetSuite's OAuth 2.0 consent screen appears. Review the permissions it lists and click Continue. The walkthrough ends before that step, and the data a user can read through the connector is limited by the role they authorize with and by what the script does. After later script updates, role changes or sandbox refreshes, expect to check the deployment and ask users to authorize again.
Common questions
Which SuiteCloud features does a RESTlet connector need?
For a RESTlet called from outside NetSuite with OAuth 2.0, the normal account-level requirements are Server SuiteScript, REST Web Services and OAuth 2.0. The vendor's package can need more, which is why the walkthrough also ticks Client SuiteScript, SuiteScript Server Pages, SOAP Web Services and SuiteSignOn. Follow the vendor's current list. Token-based Authentication is a separate method and is not needed for an OAuth 2.0 connection.
What does Company-wide Usage do on the script file?
It makes the File Cabinet file available throughout the account instead of only to its owner, so a deployed script can load it when it runs for other users. It grants no record permissions, does not give anyone access to the RESTlet and does not let anyone change the file.
Why upload the .js file and not the .zip?
The Script File list on Upload Script File takes the script itself. The vendor's download is a .zip, so unzip it first and upload the .js file inside. If the package holds more than one file that the script needs, upload those as well.
What does Save and Deploy do?
It saves the script record and opens a new deployment form for that script. NetSuite can fill in the deployment title from the script name. The deployment is not ready for use until you save it with the right status and audience.
What is the difference between Testing and Released?
Testing is for controlled testing, not for normal use. Test it as the script owner before you release it. Set the status to Released, keep Deployed ticked and have a user who is not an administrator try the connection. Released alone does not give anyone access. The user still needs the role permissions the script requires.
Which Log Level should I use?
Use Debug while you set up the connection. It is the most detailed level and can store a lot of data. Audit keeps audit, error and emergency messages, Error keeps error and emergency messages, and Emergency keeps only emergency messages. For normal running, choose the quietest level that still lets you monitor the script, and keep tokens, customer data and large payloads out of the logs.
Who should be in the deployment audience?
Select All for Internal Roles and Employees is the simplest choice and the widest. For production, select only the roles and employees who will connect, ideally a dedicated role with just the permissions the connector needs. The audience controls who can call the deployment. It does not grant record permissions, so the user's role still needs its own, including permission to log in with OAuth 2.0 and to use REST Web Services.
Which URL goes on the vendor's page?
The External URL from the saved deployment, not the relative URL. It looks like https://<account ID>.restlets.api.netsuite.com/app/site/hosting/restlet.nl?script=<script>&deploy=<deployment>. Copy the generated value instead of building it, because account domains and numbers differ.
Do other users repeat this setup?
No. The account setup is done once by an administrator. Each user then authorizes from the add-in's sidebar and sees NetSuite's OAuth 2.0 consent screen. Whether every user must authorize separately depends on the vendor's connection model, and some vendors also need an OAuth 2.0 client registered in NetSuite, so follow the vendor's instructions for that.
What is the account ID for a sandbox?
Sandbox IDs add a suffix, such as 1234567-sb1 in the address and 1234567_SB1 as an account ID. These are common forms, not rules to apply by hand. Confirm the value under Setup > Company > Company Information and use the form the vendor asks for. Do not enter the production ID for a sandbox setup.
The vendor's page saved the URL but a user cannot connect. What should I check?
Check that the deployment is Released and Deployed, that the user's role is in the audience, that the role has permission to log in with OAuth 2.0 and use REST Web Services, and that the script file has Company-wide Usage. Also check the vendor's own requirements for an OAuth 2.0 client and redirect address.