Skip navigation

Developer Community

5 Posts authored by: bryanbarnard Employee

ServiceNow / example-restclient-myworkapp-nodejs




Today I want to introduce the first in a series of example application projects will be hosted on GitHub that illustrate how various types of clients (Web, Mobile, IoT Device, Hybrid) can connect to ServiceNow by using the platform REST APIs and Scripted REST APIs that the ServiceNow platform provides.


These projects will include source code and documentation on how to get setup as well as how the application works so you can quickly check out an example client application that connects to ServiceNow REST APIs. Go ahead and clone the Node.js myworkapp, give it a try and let us know what you think. We’re looking forward to hearing what you think and seeing what you build.


The Node.js myworkapp example app can be found on GitHub under the ServiceNow organization. Look for “example-restclient” in the name and you’ll see that there are currently repos for the myworkapp-nodejs and myworkapp-ios projects. The myworkapp-nodejs is ready for you to take a look at today and in the next few weeks we’ll have the myworkapp-ios example ready. These are the first two example apps in a series we have planned so stay tuned you’ll soon hear about more example apps we are working on.




Each of the example client applications follow the pattern of providing a client application in a different format/language that relies on the same ServiceNow platform REST API and Scripted REST API for their backend. In this way each example app provides a client in a different format/language but all of them user HTTPS to communicate with a ServiceNow instance. For those of you familiar with the TodoMVC you may see the similarity here.


The custom Task Tracker Scripted REST API (included in the repo and available on share) acts as a simple API Gateway providing a REST API that gathers data from various underlying apps/tables in the ServiceNow instance and returns a list of all tasks that are active and assigned to the requestor (based on credentials included in the request). The platform REST Table API is then being used to gather comments for each task and to lookup details about the requesting user. We are using the REST Table API to illustrate that the client application could use multiple APIs to gather data but we could have also chosen to implement all of the functionality in the Task Tracker Scripted REST API.


More about ServiceNow REST APIs


ServiceNow provides REST APIs that allow developers to connect their applications to ServiceNow using protocols (HTTPS) and data formats (JSON/XML) that they expect and are familiar with. In addition to providing platform REST APIs that support CRUD operations on any data table in the platform developers also have the ability to create their own REST APIs (using ServiceNow Scripted REST APIs) that provide custom interfaces for their applications and data.


The ability for developers to create custom REST APIs is a recent addition and was introduced in the ServiceNow Geneva release as Scripted REST APIs. Scripted REST APIs meet customers need to be able to create a custom interface for a variety of reasons including; to integrate with a 3rd party service that didn’t allow flexibility in the format of the request payloads it sent to ServiceNow (e.g., WebHooks, IoT Sensor Posts), to provide an API Gateway style interface for interacting with their applications and data in ServiceNow, to return custom payloads to their WebApps or UI Pages using modern frameworks like AngularJS or KnockoutJS, to provide custom interfaces to meet their customers needs.


You can find out more about ServiceNow, ServiceNow REST APIs, and our developer program via the following links:

ServiceNow Developer Program

ServiceNow REST API Reference

Scripted REST APIs Reference

Blog Post: Introducing Scripted REST APIs



Hopefully you heard at our recent webinar (if not check back as we’ll have the recording posted soon) at CreatorCon this year we will be setting aside space called the unconference zone specially to allow attendees to setup and facilitate short ad-hoc talks about topics of their choosing.


So what is it?

If you’ve never been to an unconference or open spaces format conference before you are likely wondering what the heck I’m talking about. You may be asking yourself why would I go to a conference to hear myself talk? It’s a simple concept really, the idea is to provide time and space where participants who all share some common interest (in this case it’s ServiceNow) the opportunity to informally exchange ideas. Have you ever been to a conference only to find the topic you are most interested in absent from the agenda or wished you could have had a chance to carry on the conversation that started in a session? With an unconference format you have that opportunity. Keep reading and I’ll explain how this works.


How does it work?

At CreatorCon we will have spaces dedicated to unconference sessions. Details are still being worked out regarding exactly how many spaces we will have but expect at least two spaces that will be set aside with large whiteboards, video screens and ~15-20 chairs where sessions can be held. Near the entrance to the CreatorCon hall you will find signs directing you to where you can find information about what unconference sessions are scheduled and where they will take place. The first thing you should expect to see is a bunch of giant post-it notes on a grid on a wall or board.

Here you will be able to *propose a session* by simply writing your topic title on a giant post it and putting it on the slot on grid that indicates an open time and space. [Best Practice] Choose a topic title that will help people quickly understand what you want to talk about or continue adding a sub-title *and* include your name and email address on the post-it That’s all there is to it.


Ok, so I just proposed a session now what? By proposing a session you are expected to do a few simple things… (the plot thickens). First, if you proposed a session you are expected to show up at the time and space you chose and facilitate the conversation. You are not expected to have all the answers or be an expert on this topic, you don’t even have to stand up in front of a crowd. You should just be interested in your proposed topic, be willing to kick-off the conversation and if appropriate take notes about the conversation on the white board. That’s it.


Don’t have a topic in mind yet, that’s ok just show up. There is no need to do anything to prepare for attending the unconference zone prior to attending CreatorCon.


Why are we doing this?

A few of us (myself included) here at ServiceNow have been to unconferences before and have had very positive experiences. We want to bring this experience to CreatorCon attendees as we feel it gives attendees a great chance to make sure they can have the conversation/talk that is most important to them. No amount of planning can anticipate every topic of interest to every attendee. Sessions in the main Knowledge are designed to have broad appeal to the attendees. Here you do the opposite; go as narrow and deep as you want to. No matter how specific, it will be of interest to someone else. Want to talk about integrating ServiceNow with AWS but don’t see a scheduled session? Propose one. Want to talk about React but don’t see a session, grab a giant post-it and propose it. At an unconference the ball is in your court to have the conversation about the topic you want to talk about. Want to discuss rate limiting APIs in ServiceNow, PROPOSE A SESSION (I’ll attend).


I’m really looking forward to seeing what type of sessions occur and how the community uses this space!!


You can learn more about the unconference (aka open spaces) format at following the links and stay tuned for follow up posts that will give you tips and tricks to make the most of your time at an unconference and for more details regarding how many spaces and time slots we’ll have at our unconference zone.


- unConferencing – how to prepare to attend an unconference |

- Unconference - Wikipedia, the free encyclopedia

Confused about how to use OAuth 2.0 to authenticate to ServiceNow REST APIs? Check out this new video tutorial the walks through setting up OAuth 2.0 and making requests to ServiceNow REST APIs using OAuth 2.0.



Topics Covered:

About OAuth

Comparison of basic authentication and OAuth requests

Setting Up OAuth on a ServiceNow instance

Requesting tokens

Using tokens to make REST API requests

Requesting a new access token

Issuing requests from a terminal using curl


ServiceNow product documentation:

Enable OAuth with inbound REST

Set up OAuth

Use a third-party OAuth provider

OAuth tokens

OAuth API request parameters

I'm excited to announce that we've released new REST API documentation on the ServiceNow Developer Portal. You can find the new docs by selecting API from the top menu and then choosing REST. Here you'll find developer focused documentation on ServiceNow Platform REST APIs including detailed documentation on the resources, parameters, status codes, authentication along with code samples in curl and python for making requests and sample responses.


ServiceNow Developer REST API Documentation



Today we have coverage of the REST APIs available in the Fuji and Geneva release (note you can select the release specific docs in the bottom right hand corner) including the Table, Import Set, Aggregate, and Attachment API (Geneva only). We will add coverage of additional REST APIs that are available soon.


Hope you enjoy and please let us know any feedback you have positive or negative so we can make these docs better over time!




If you've used ServiceNow for a bit then you are probably familiar with using Dot-walking to access data on related records. In case you are new to the concept here is the definition and a link to product documentation.

From the product docs:

"Dot-walking in ServiceNow provides access to fields on related tables from a form, list, or script. If the current table contains a reference to another table, any field on the referenced table can be accessed using dot-walking."

I use dot-walking all the time in ServiceNow to help me view data about related records without needing to navigate to the referenced record. ServiceNow makes it really easy to dot-walk via the UI in lists and scripts but how can I leverage this functionality when using the REST Table API?

The REST Table API (available in the Eureka release and after) supports dot walking for GET requests via the sysparm_fields parameter. This parameter allows you (the requester) to provide a comma-separated list of field names that will be returned in the response. The most common use of the sysparm_fields parameter is to limit the fields that will be returned in the response. For example if you are using the ServiceNow REST Table API to query incident records if you make the following request you will receive a response that contains all the fields that you have access (permissions) to read in ServiceNow (on most systems this result in 40+ fields being returned.

Sample Request to a ServiceNow Demo Instance - All Fields

Sample Request Table API to GET an Incident · GitHub


GET /api/now/table/incident?sysparm_limit=1 HTTP/1.1

Authorization: Basic <removed on purpose>


Connection: close


Sample Response - All Fields

Sample Response · GitHub


HTTP/1.1 200 OK


  "result": [


      "skills": "",

      "upon_approval": "",

      "location": {

--- response cut off to save space --- see the GitHub Gist for full response content.


We can use the sysparm_fields parameter to limit the fields returned in the response. For example we can only include the number and location field by adding the sysparm_fields parameter as shown in the following request/response.

Sample Request to a ServiceNow Demo Instance - using sysparm_fields to limit response

sample request using sysparm_fields · GitHub


GET /api/now/table/incident?sysparm_limit=1&sysparm_fields=location,number HTTP/1.1

Authorization: Basic YWRtaW46YWRtaW4=

Accept: application/json


Connection: close

Sample Response - using sysparm_fields to limit response

Sample Response - using sysparm_fields to limit response · GitHub


HTTP/1.1 200 OK


  "result": [


      "location": {

        "link": "",

        "value": "1083361cc611227501b682158cabf646"


      "number": "INC0000001"





When using the sysparm_fields parameter we were able to limit the response to only include the location and number field from the incident. Location is a reference field on Incident and refers to a record in the cmn_location table. cmn_location records have multiple fields including a name and city field but they are not included in the response by default. So how can we have those fields included in our response? That is where dot-walking comes in. You can dot-walk in the REST Table API using the sysparm_fields. If I add the name and city to the sysparm_fields parameter I can have them included in the response as is shown in the request and response below.


Sample Request to a ServiceNow Demo Instance - using sysparm_fields dot-walk

Sample Request to a ServiceNow Demo Instance - using sysparm_fields dot-walk · GitHub

GET /api/now/table/incident?sysparm_limit=1& HTTP/1.1

Authorization: <removed>

Accept: application/json


Connection: close


Sample Response to a ServiceNow Demo Instance - using sysparm_fields dot-walk

Sample Response to a ServiceNow Demo Instance - using sysparm_fields dot-walk · GitHub


HTTP/1.1 200 OK


  "result": [


      "": "Oklahoma",

      "location": {

        "link": "",

        "value": "1083361cc611227501b682158cabf646"


      "number": "INC0000001",

      "": "Oklahoma"




Filter Blog

By date: By tag: