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 has multiple URLs for the production roles service. Each data center hosts the service on its own REST domain. However, you don't need to know your account's data center when sending a request. So, you can use any production URL. But note that your request might be redirected to a different URL, as described next. To find 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
Calls to the roles service may 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 might be redirected to a different URL. Redirection happens because these requests need to be handled by the same data center hosting the NetSuite account. So, if you have an integration making this type of call, it should 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've never called the roles service before. It's okay if you don't know. The service lets you send requests to any available production URL. 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. So, your integration should handle the 302 Found response status code, which indicates redirection.
By contract, if your authorization header omits a NetSuite account ID, your request is handled without redirection.