What roles do you actually need for REST API communication?

[Joey Alain1]

Over the last few weeks I've noted that the Service Now Docs portal seems to have a few pages outlining the roles you should require if you want to interface with your instance via the REST API.

Specifically it notes the following:

1) If you wish to view the REST API Explorer, this page walks you through doing that.

Getting started with REST - access the REST API Explorer

This one is fairly straight forward. The REST API Explorer is a visual tool to help you build and review, REST API calls. It itself doesn't make any calls (other than testing) but it's a great starting point to get your bearings as you begin building in REST API calls elsewhere which will leverage this.

2) Now, moving on. What if I have an external process (PowerShell Script, other script, other web service), which I want to use to query my CMDB and pull some records out. What do I need in order to do that?

Getting started with REST - retrieve existing incidents

This article outlines what you need in order to begin actually making calls via this web service. Of note, it indicates you require one of the following roles: web_service_admin, rest_api_explorer, or admin.

3) Here is where things get confusing for me. See this article: SOAP roles. In this article, it goes everything the roles related to the SOAP API.

Now, let's fast forward to today's problem. I'm getting started with ServiceNow, automation and more specifically, orchestration and as a first step have requested our SNOW group provision me a service account which I will use to make the REST API calls from within whatever script or service I'm working from. Here's what I've been given so far:

- My domain account which I use to log into our SNOW portal has been granted the role: REST_API_EXPLORER. And, as expected, it allows me to view the REST API Explorer window while logged in as me.

- I have a service account now which has been granted the role: soap_ecc.

Now, I'm not using SOAP. Don't want to, don't plan on it. Yet I can make GET HTTP calls to the REST API web service, and they are successful, using this account. So here's my questions(s).

1) Why is this the case? Does the SOAP web service use the same listeners as the REST API web service so at this level, the roles do the same? I would have expected the service account would require at least one of the roles outline in the 'Getting Started with REST' article above, yet that doesn't seem to be the case.

2) If the above is true, then I worry that we really don't properly understand what roles we need for each. I was under the impression that my regular account would require the REST_API_EXPLORER role to work in the REST windows, and that my service account would require the WEB_SERVICE_ADMIN role to properly communicate with the REST API web service.

Where am I going wrong? Is there some role inheritance here that I'm missing? Why do I require any SOAP related roles at all, anywhere? Just looking for some clarification on how all of this is laid out.

Thanks,

[jberk · Accepted solution]

Go look at the tables you are able to do GET requests against and their ACL's. Likely the READ activity is not restricted by any roles and therefore as long as the user has an account, even with no roles, they would be able to see the tables/records.

[mayank26_]

Is this issue resolved @jalain ? I have similar scenario and I cant ask my admin team to provide me admin access. I am looking for specific roles that should be granted so that I could do REST API calls without any issues. 

[Joey Alain1]

@mayank26_  I'd recommend you examine the activities you're trying to do and base the role requirements off of those. @jberk is partially correct and for some read activities you really don't need much in the way of roles.

For most create/update/delete activities however, the roles may be different depending on what you're doing. I'm doing a lot of work using the RESTful interface in ServiceNow right now, and I'm using import set API's to do it. For those I'm using other roles entirely (import_scheduler and import_transformer) for example. 

So it's going to be slightly different for each person. 

Hope that helps,