ServiceNow Rest API throwing error (401 UNAUTHORIZED)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-25-2019 03:23 AM
Hello Experts,
I am using the below command from a unix machine.
curl -v "https://<instancename>/api/now/table/incident?sysparm_query=assigned_to=aea28412db295704e744f1e51d96194c" --request GET --header "Accept:application/json" --header "X-userToken:window.g_ck" --user "username":"password"
And the response I am getting is:
* About to connect() to **********.service-now.com port 443 (#0)
* Trying 149.96.37.37... connected
* Connected to ********.service-now.com (1.9.3.3) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.service-now.com,O=ServiceNow,L=San Diego,ST=California,C=US
* start date: Jul 09 13:47:20 2018 GMT
* expire date: Apr 01 14:17:19 2019 GMT
* common name: *.service-now.com
* issuer: CN=Entrust Certification Authority - L1K,OU="(c) 2012 Entrust, Inc. - for authorized use only",OU=See www.entrust.net/legal-terms,O="Entrust, Inc.",C=US
* Server auth using Basic with user '********'
> GET /api/now/table/incident?sysparm_query=assigned_to=aea28412db295704e744f1e51d96194c HTTP/1.1
> Authorization: Basic WDQ4Njg5MjpSYXZhbGlAMDI=
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: **********.service-now.com
> Accept:application/json
> X-userToken:window.g_ck
>
< HTTP/1.1 401 Unauthorized
< Set-Cookie: JSESSIONID=87F06C59DA9D8FFB5DED9F82DF96F480; Path=/; HttpOnly;Secure
< WWW-Authenticate: none
< X-UserToken-Request: window.g_ck
< X-UserToken-Response: 4ac63d5013d3a300926635528144b048f189c7d1a585d348744333243ea898672cfcdabb
< X-SessionLoggedIn: false
< X-HandleTimeOut: true
< X-AutoResubmit: true
< X-UserToken-AllowResubmit: false
< Pragma: no-store,no-cache
< Cache-control: no-cache,no-store,must-revalidate,max-age=-1
< Expires: 0
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Fri, 25 Jan 2019 11:17:39 GMT
< Server: ServiceNow
< Set-Cookie: BIGipServerpool_*********=226499850.38974.0000; path=/; Httponly; Secure
< Strict-Transport-Security: max-age=63072000; includeSubDomains
< Connection: close
<
* Closing connection #0
{"error":{"message":"User Not Authenticated","detail":"Required to provide Auth information"},"status":"failure"}
I have used the same credentials to login the ServiceNow console and credentials work perfectly fine.
Any help on this matter is much appreciated.
Thanks

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-28-2019 07:21 AM
Hi Arpit,
I tested with the curl command that you provided on my instance and it works.
Also, I do not think this is a role issue. When a role is required and your account does not match that role you get this:
{"error":{"detail":"Failed API level ACL Validation","message":"User Not Authorized"},"status":"failure"}
There is an ACL that is inactive by default called "Table API" which check for role "snc_platform_rest_api_access".
After looking at the curl output that you provided and comparing it to the curl output from my instance leads me to wonder about the curl configuration.
add "--insecure" to tell curl not to verify the certificate. Is this works then you need to work with your Linux admin to adjust your local CA store.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-28-2019 11:31 PM
Thanks Chris. I tried using --insecure (and -k) option with curl, still it is giving the same error. I am not sure what is causing it to fail.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-28-2019 11:53 PM
I created a developers Servicenow instance and added a user in it that has no associated roles. Please see the screenshot below.
And I was able to test the same REST API with this user without any issue.
Still scratching my head what is causing the issue with the instance I want to use it on.
a) its not the curl syntax
b) It may not be the Roles as well because I am able to use REST API with a user with no roles associated.
c) it is not account locked or credentials issue

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-29-2019 08:38 AM
What we know:
1. The same curl command from the same Linux host work on all instances that you tested except one. (we will call it instance "X")
2. The curl command fails with a 401 Unauthorized only on instance X.
3. You can log in to the UI on instance X and access all of the same records that the REST API call could access. (Is this true?)
Assumptions
1. It looks like you are trying to access the incident table and the sysid for assigned to, which is probably for your account?
2. This account has ITIL
3. You checked to make sure the REST Table ACL is not active.
4. You get the same error when you run a simple query against the incident table.
5. It is probably not curl nor the curl command you are sending.
Things to check
1. Are their any ACLs on Incident or User that would prevent you from accessing the incident or the user table?
2. Can you test against in a lower environment of instance X? (I.E. Test or Dev) -- This is important if it fails you know your environment has some sort of configuration that is preventing you from accessing this.
3. Do you have other credentials to test with?
4. Does instance X have SSO or something similar?
5. Does instance X have any IP address restrictions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-10-2020 08:06 AM
Something I noticed is that Postman and the Bash command "base64" to be generating different encoded strings for the same credentials. If I enter my credentials in Postman through the "Authorization" tab, my requests work, but the temporary "Authorization" header contains a different encoded string value than the one I get from the "base64" command. Strangely, the encoded authorization string which Postman generates decodes to the same credentials as I use for the input to the base64 command in Bash.