URLs for Accessing the REST roles Service
To use the roles service, you send a GET request to the appropriate URL. However, the URL that you use can vary in the following ways:
-
You use a different URL for each of the following: production, sandbox, and Release Preview accounts. For details, see Sample URLs.
-
In some cases, your request may be redirected. If you have an integration that calls the roles service, your integration must include logic to handle this redirection. For details, see Calls that May Require Redirection.
Sample URLs
You can use the following URL to call the roles service, using the GET method. This URL works for production, sandbox, and release preview accounts: https://rest.netsuite.com/rest/roles and similar variants.
NetSuite maintains multiple URLs for the production version of the roles service. Each data center hosts the service on the REST domain specific to that data center. However, you are not expected to know the data center of your account when you send the request. For that reason, you can use any production URL. But be aware that, in some cases, your request may be directed to a different URL, as described in the next section. For a list of all REST service domains, see Understanding NetSuite URLs.
Account-specific domains are supported for RESTlets, and you can access your RESTlet domain at the following URL, where <123456> is a variable representing your account ID: <123456>.restlets.api.netsuite.com. For more information, see URLs for Account-Specific Domains.
As of 2020.1, when you call the REST roles service on an account-specific domain, only the account specific information is returned. All roles are returned for the user, including the Customer Center roles, and any roles created based on the Customer Center role.
Calls that May Require Redirection
Sometimes calls to the roles service include a NetSuite account ID in the authorization header. If you send this type of request to a production version of the roles service, the call may be redirected to a different URL. Redirection can occur because these requests must be handled by the same data center that hosts the NetSuite account. For this reason, if you have an integration that makes this type of call, the integration must include logic to handle redirection.
For example, suppose you are calling the service to retrieve roles information for a user in your NetSuite account. You may not know which data center your account is hosted in, especially if you have never called the roles service before. This knowledge gap is expected. The service is designed so that you can send your request to any of the available production URLs for the service. However, if your account is hosted in the EU and you send the request to a URL associated with a North American data center, your request will be redirected to https://rest.eu2.netsuite.com. For this reason, your integration must include logic for handling the 302 Found response status code, which is the code used when redirection occurs.
By contract, if your authorization header omits a NetSuite account ID, your request is handled without redirection.