Udemy
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
Turn what you know into an opportunity and reach millions around the world.
Learn More
Your cart is empty.
Keep shopping
ServiceNow - Learn Scripted REST APIs and Integration
Highest Rated
Rating: 4.6 out of 5(41 ratings)
262 students

ServiceNow - Learn Scripted REST APIs and Integration

Learn Scripted REST APIs and Integration in ServiceNow with Real-API Projects
Created byLukasz Szumilas
Last updated 2/2025
English

What you'll learn

  • How to Build Scripted REST APIs: Create, test, and manage custom APIs in ServiceNow for various use cases.
  • Integrating External Services: Learn how to connect with WeatherAPI and IPLookup to fetch and use real-time data.
  • Discovering APIs on the Internet: Explore external APIs available online and learn how to pull and integrate their data into ServiceNow.
  • Creating Bidirectional Integrations: Develop two-way integrations between ServiceNow instances, focusing on secure and reliable data sharing.
  • Securing APIs: Implement best practices for authentication and authorization, including OAuth and access control rules.
  • Debugging and Testing APIs: Use tools like REST API Explorer and Postman to troubleshoot and optimize your APIs.
  • Managing API Versions: Learn how to version APIs to support updates without breaking existing functionality.

Course content

8 sections65 lectures9h 7m total length
  • ServiceNow as a Web Service Consumer2:56

    Video Text:

    Today, let’s make sense of how ServiceNow can talk to other systems on the internet using something called “web services.”

    Picture two friends who share a common language. They can exchange messages, ask for help, and share answers without any confusion. Now imagine if these two friends tried to communicate but each spoke a completely different language. They’d struggle, wouldn’t they? That’s often the case for different applications—they’re built with different programming languages and data formats. Without a common “language” or set of rules, it’s hard for them to understand each other.

    This is where web services come in. They provide a standard way for applications to talk to each other, no matter what language they’re built in. By following common rules, each system can understand the other’s requests and responses, making everything run smoothly.

    ServiceNow as a Web Service Consumer:

    Look at this diagram. On the left, we have our ServiceNow instance. Think of it as a curious student, ready to learn. On the right, we have an external application that offers data or tasks—like a teacher or a resource library. The line between them is the network, and the “language” they use to talk is called a web service.

    When ServiceNow wants something—say, a piece of data from that external application—it sends a request. This request basically says, “Please give me the info I need.” The external application is the provider. It processes the request and sends back a response. The response often comes with two key parts:

    1. A Status Code, which tells you if everything went well. (For example, “200 OK” means success.)

    2. A Response Body, which is the actual data, like a record of a user or the temperature in a certain city.

    With web services, ServiceNow can grab data from all kinds of sources—geolocation coordinates, stock info, financial data, inventory details, weather updates, language translations, and so on. Instead of opening different websites manually, ServiceNow does it for you, behind the scenes.

    Why ?

    Because why build this in ServiceNow from scratch if you can just save time and use existing apps instead.

  • What is REST ?1:32

    Video Text:

    Now that we know ServiceNow can talk to external applications using web services, let’s explore one of the most common standards they use—something called REST (Representational State Transfer).

    REST sets clear guidelines for how requests and responses should be structured. This makes it easier for any two systems to communicate, even if they’re built by different teams or in different programming languages.

    By following these REST rules, it’s like we’re all agreeing to speak the same “universal language” when we request and share data.

    For example, imagine you’re in a restaurant with a set menu.

    Everyone orders using the same terms, like 'soup' or 'steak.' The waiter understands exactly what you mean, and the kitchen knows how to prepare it. You don’t need to know how the kitchen works; you just follow the menu, and the communication is clear. In the same way, with REST, systems follow a common 'menu' of request and response formats, so they can understand each other without knowing the details of the other system’s inner workings.”

  • Benefits of REST API4:50

    Video Text:

    Lets look at 2 benefits of REST

    1. Separation of Client and Server:

    In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other. This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.

    As long as each side knows what format of messages to send to the other, they can be kept modular and separate. Separating the user interface concerns from the data storage concerns, we improve the flexibility of the interface across platforms and improve scalability by simplifying the server components. Additionally, the separation allows each component the ability to evolve independently.

    By using a REST interface, different clients hit the same REST endpoints, perform the same actions, and receive the same responses.

    Imagine the external application as a restaurant’s kitchen, and ServiceNow as the customer.

    The restaurant can change its menu or how it cooks meals (server-side changes) without telling the customer. They can process their data the way they want, but still what they provide as a web service doesn’t change.

    Or customer can change the way they eat the meal, without directly affecting the kitchen. Its on them how they use what they got.

    Both sides evolve independently, as long as they stick to the agreed way of ordering and serving.

    2. Statelessness

    Systems that follow the REST paradigm are stateless, meaning that the server does not need to know anything about what state the client is in and vice versa. In this way, both the server and the client can understand any message received, even without seeing previous messages. This constraint of statelessness is enforced through the use of resources, rather than commands. Resources are the nouns of the Web - they describe any object, document, or thing that you may need to store or send to other services.

    Because REST systems interact through standard operations on resources, they do not rely on the implementation of interfaces.

    These constraints help RESTful applications achieve reliability, quick performance, and scalability, as components that can be managed, updated, and reused without affecting the system as a whole, even during operation of the system.

    Each request ServiceNow makes stands on its own. The server doesn’t have to remember what you asked for before.

    It’s like every time you place an order at a restaurant, you hand over a note with all the details, so the waiter doesn’t need to recall your previous meal. This makes everything simpler, more efficient, and easier to scale.

  • API - The Waiter Analogy3:58

    Video Text:

    API stands for Application Programming Interface.

    Imagine you’re in a restaurant:

    • You (the client) ask the waiter (the API) for a dish (data).

    • The waiter talks to the kitchen (the external provider) and brings back your meal (the response).

    • You didn’t need to cook it yourself or even know how the kitchen works. You just made a simple request and got what you wanted.

    In the same way, ServiceNow doesn’t need to know all the details about the external app’s database. It just needs to know how to ask (the endpoint, headers, and method) and how to understand the answer (the response data).

  • Communication between Client and Server0:33

    Video Text:

    Communication between Client and Server

    In a REST architecture, clients issue requests to fetch or change resources, while servers reply with responses.

    Let’s explore the common methods used to send these requests and provide responses.

  • Making Requests0:48

    Video Text:

    Making Requests

    In a RESTful setup, the client must send a request to the server to retrieve or modify data. Each request includes:

    • An HTTP verb (GET, POST, PUT/PATCH, DELETE) specifying the type of action.

    • Headers to pass along extra details about the request.

    • A Path to a resource indicating what you want to access or change.

    • An Authentication restricting who can access

  • HTTP Methods2:21

    Attention !

    These are theory lectures. We will be configuring everything on our instance (PDI) later on, but i wanted to explain the concepts on already configured REST Message, so you see from the start how it could be configured and look.

    Don't worry that you don't have this configured yet, we will configure everything in upcoming lectures.

    I just think you will learn better if you will see some concepts multiple times, thats why first i show theory and then explaing how to configure from scratch, which is more practical.
    Video Text:
    HTTP Methods

    When ServiceNow needs information from a RESTful web service, it sends such an HTTP request. Typically, these four main methods are used:

    • GET: Retrieve existing data.

    • POST: Create new data.

    • POST: Create new data.

    • PUT/PATCH: Update existing data.

    • DELETE: Remove data.

    For instance, if ServiceNow wants the current weather for a city, it can send a GET request to a weather service’s URL, like https://api.weatherprovider.com/current?city=London. If everything works correctly, the server replies with a 200 OK status and returns weather details in a format such as JSON, for example: { "temperature": "15°C", "condition": "cloudy" }.

  • Headers and parameters4:35

    Video Text:

    Headers and Accept parameters

    Beyond choosing the right HTTP verb, clients can also include headers in their requests. One key header is Accept, which tells the server what kinds of content the client can handle. The server then aims to return the response in one of those supported formats.

    MIME Types (Multipurpose Internet Mail Extensions) define these formats, using a type/subtype structure. Two common data exchange formats are JSON and XML:

    • application/json for JSON data

    • application/xml for XML data

    If you specify Accept: application/json in your request, you’re telling the server: “I prefer JSON.” If it can’t provide JSON but you also listed application/xml, the server might respond with XML instead. This flexibility ensures you get data in a format ServiceNow can easily process.


    For example, if ServiceNow wants the current weather for a city (like London), it might send a GET request to a weather service’s URL:


    GET <https://api.weatherprovider.com/current?city=London>

    Accept: application/json, application/xml


    This request means ServiceNow will accept either JSON or XML. If the server returns JSON, it might look like this:


    HTTP/1.1 200 OK

    Content-Type: application/json

    {

      "temperature": "15°C",

      "condition": "cloudy"

    }


    If it decides to return XML instead, you might see:


    Content-Type: application/xml

    <weather>

      <temperature>15°C</temperature>

      <condition>cloudy</condition>

    </weather>


    In ServiceNow’s Outbound REST Message configuration, you can add the Accept header directly. Just as you chose the HTTP verb (GET) and specified the endpoint (https://api.weatherprovider.com/current?city=${city}), you can also say Accept: application/json to ensure the data is returned as JSON. If you include application/xml as well, the server has the option to send data in XML when JSON isn’t available.


    Short Analogy:

    Similarly, just like a restaurant specifies which types of payment it accepts (credit card, cash, etc.), the Accept header ensures that ServiceNow receives data in a format it can process. This way, both ServiceNow and the server communicate effectively, avoiding misunderstandings and ensuring smooth transactions.

  • What is JSON ? How to work with JSON ?14:00

    What is JSON?

    JSON (JavaScript Object Notation) is a lightweight data format used to represent structured data. It’s easy for humans to read and write, and straightforward for machines to parse and generate. JSON has become one of the most common formats for exchanging data between clients and servers in RESTful APIs.

    Key Points:

    • Text-Based Format: JSON is plain text, making it easy to transfer across networks.

    • Language-Neutral: Although inspired by JavaScript, JSON can be used with any programming language, including the ServiceNow platform.

    • Structured and Self-Describing: JSON uses a simple syntax with key-value pairs and arrays, making data clear and hierarchical.


    JSON Structure

    A JSON object is enclosed in curly braces { }. Inside, data is represented as key-value pairs. Keys are always strings, and values can be:

    • Strings

    • Numbers

    • Booleans (true/false)

    • Objects (another set of key-value pairs)

    • Arrays (ordered lists of values)

    • null

    Example:


    {

      "name": "Alice",

      "age": 30,

      "isEmployee": true,

      "skills": ["ServiceNow", "JavaScript", "REST"],

      "address": {

        "city": "New York",

        "postalCode": "10001"

      }

    }


    This JSON object describes a person named Alice, her age, employment status, skill set, and address details. Notice how key-value pairs are separated by commas, and arrays or objects nest data for clarity.


    JSON in RESTful APIs

    When ServiceNow makes a request to a RESTful API, it often specifies Accept: application/json to indicate it wants the response in JSON format. The server then returns data in JSON, allowing ServiceNow to parse it easily.

    For example, retrieving weather data might yield:


    {

      "temperature": "15°C",

      "condition": "cloudy",

      "humidity": 65

    }


    ServiceNow can then use script logic to extract these values and display them on a form or store them in a table.


    Why JSON Matters to ServiceNow Integrations

    • Ease of Integration: Since JSON is widely supported, ServiceNow can interact with most APIs that provide or accept JSON data.

    • Simple Parsing and Serialization: In server-side scripts, ServiceNow developers can quickly parse JSON strings into JavaScript objects and vice versa, making data manipulation straightforward.

    • Reduced Complexity: JSON’s clear structure makes it easy to understand what data is being returned, speeding up development and troubleshooting.


    JSON vs. Other Formats

    • JSON vs. XML: Both can represent complex data, but JSON is typically more concise and easier to parse, with less overhead.

    • JSON vs. HTML: HTML is for displaying content on web pages, while JSON is purely for data exchange. JSON doesn’t handle layout or styling—it focuses solely on representing data in a structured way.


    For most integrations, JSON’s simplicity, readability, and language neutrality make it a preferred choice.


    Working with JSON in ServiceNow

    It’s important to remember that JSON data is initially just a string. To work with it in scripts, you need to parse it into a JavaScript object. Once parsed, you can easily read and manipulate the data.


    Parsing JSON:

    ServiceNow provides the JSON() API in server-side scripts. For example, if you receive a JSON string from a REST API call, you can do something like:


    var jsonString = '{

      "name": "Alice",

      "age": 30,

      "isEmployee": true,

      "skills": ["ServiceNow", "JavaScript", "REST"],

      "address": {

        "city": "New York",

        "postalCode": "10001"

      }

    }';


    // Parse the JSON string into a JavaScript object

    var dataObj = JSON.parse(jsonString);



    Now dataObj is a JavaScript object, and you can access its properties directly:


    gs.info("Name: " + dataObj.name); // "Alice"

    gs.info("Age: " + dataObj.age); // 30

    gs.info("City: " + dataObj.address.city); // "New York"



    Modifying Data:

    Since dataObj is now a regular JavaScript object, you can modify its values, add new properties, or remove existing ones:


    dataObj.skills.push("IntegrationHub"); // Add a new skill

    dataObj.age = 31; // Update Alice's age

    delete dataObj.isEmployee; // Remove the isEmployee property



    Re-Stringifying the Object:

    If you need to send the updated data back as JSON in another request, you can convert the object back to a JSON string:


    var updatedJsonString = JSON.stringify(dataObj);

    gs.info(updatedJsonString);



    This updatedJsonString can then be used as a request body in a POST or PUT request, or logged for debugging purposes.


    Summary:

    • JSON is initially a string: You receive it as text from APIs.

    • Parse JSON into an object: Use json.parse() to turn it into a JavaScript object you can manipulate.

    • Manipulate and re-serialize: Add, remove, or change properties, then convert it back to a string with json.stringify() if needed.


    By understanding these steps, you can integrate JSON data seamlessly into your ServiceNow workflows, using it to power dynamic interfaces, automate tasks, and connect to external systems with ease.

  • Paths3:14

    Video Text:

    In RESTful APIs, every request must include a path that specifies the exact resource the client wants to interact with. The path is part of the endpoint URL and provides a clear route to the desired data or functionality.

    Key Points:

    • Structure of Paths:

      Paths are designed to be clear and descriptive, often following a hierarchical structure. The first segment of the path is typically the plural form of the resource name, making nested paths easier to read and understand.

    • Example Structure (Weather API):

      Consider https://api.openweathermap.org/data/2.5/weather. This indicates you’re accessing the weather resource within the OpenWeatherMap API. Even if you’ve never seen this URL before, the path conveys its purpose clearly.

    • Specificity:

      Paths should include all necessary information to locate a resource. For collections, no ID is needed. For example, a POST to https://api.openweathermap.org/data/2.5/weather doesn’t require an ID; the server uses query parameters to determine what data to return.

    • Accessing Single Resources:

      To get a specific resource, append identifying details to the path. For example:


      GET <https://api.openweathermap.org/data/2.5/weather?q=London&appid=${apikey}&units=metric>


      Here, query parameters (q=London, appid=${apikey}, units=metric) provide the details needed to retrieve London’s weather data.

    ServiceNow Context:

    When configuring an Outbound REST Message in ServiceNow, it’s essential to define the endpoint path accurately. By setting up variables like ${city}, ${apikey}, and ${units}, you can easily adjust queries without modifying the entire path. This approach leads to more reliable and maintainable integrations.


    Paths and the Restaurant Analogy

    Analogy:

    Think of the path in a RESTful request like navigating a restaurant’s menu. The menu is divided into categories—appetizers, main courses, desserts—and each dish within a category has a unique number.

    • Hierarchical and Descriptive:

      Just as “/maincourses/12” would tell you to order dish #12 in the main course section, a REST path guides you to the exact resource. There’s no confusion about where to look or what you’re getting.

    • Clarity Over Guesswork:

      You wouldn’t ask for “the second appetizer” without mentioning which restaurant you’re in or which category you’re referencing. Similarly, REST paths specify the exact resource so there’s no guesswork.

    • No Extra IDs Needed for Collections:

      When creating something new (like placing a custom order), you don’t need to provide an ID upfront. The restaurant (server) will assign one. In the same way, a POST request doesn’t always need an ID—the server handles it behind the scenes.

  • Authentication3:00

    Video Text:

    Authentication

    Many APIs require authentication to ensure that only authorized clients can access their data. When working with RESTful APIs, authentication often involves passing credentials or tokens so the server knows who you are and what you’re allowed to do. Common methods include:

    Basic Authentication: A username and password combination, often encoded and sent in a header.

    OAuth 2.0: A more complex method using tokens that expire and can be refreshed, allowing more secure, controlled access.

    With proper authentication configured, ServiceNow can safely interact with external APIs, retrieve data, and perform actions without exposing sensitive information or breaking security rules.

    Analogy:

    Think of authentication as showing your ID at a restaurant before entering a special VIP lounge. If you don’t have the proper credentials, the waiter won’t let you in. With the right “ID” (API key, username/password, or token), the restaurant knows you’re allowed to access this exclusive area. Similarly, a properly configured REST Message with authentication tells the server you’re a trusted client, granting you access to the resources you need.

  • What is REST ?

Requirements

  • Basic Understanding of ServiceNow: Familiarity with the platform, including how to navigate and use basic features. Although all is shown in the course.
  • Knowledge of JavaScript: A basic understanding of JavaScript is helpful, as scripting will be covered throughout the course. But i explain each line i use.
  • ServiceNow Personal Developer Instance: Access to a personal developer instance of ServiceNow to practice and complete exercises. We will request that on the video.
  • Eagerness to Learn: No prior experience with REST APIs or integrations is necessary, as all concepts will be explained clearly and step by step. Beginners are welcome!

Description

ServiceNow - Learn Scripted REST APIs and Integration

Do you want to build secure and reliable integrations in ServiceNow? In this course, I will guide you step by step through creating Scripted REST APIs and Real-World integration projects. Whether you are new to ServiceNow or already have some experience, you will gain the skills to handle complex integrations with confidence.

What You Will Learn

  1. Scripted REST APIs:

    • Build, test, and manage your own APIs in ServiceNow.

    • Create endpoints for common tasks such as creating, reading, updating, and deleting records.

    • Apply versioning to support ongoing changes without affecting current users.

  2. Real Projects That Matter:

    • CityWeatherInfo Application:

      • Design a complete application to manage weather data for different cities.

      • Set up roles, groups, tables, and fields that form the backbone of the app.

      • Create multiple API endpoints to interact with external data from services like OpenWeather.

      • Implement a business rule that automatically updates weather data when records are added or changed.

      • Use a scheduled job to refresh data regularly and create simple dashboards to visualize information.

    • Two-Way Instance Integration:

      • Keep user records synchronized between two ServiceNow instances.

      • Use business rules to trigger REST calls when a user record is created or updated.

      • Compare update timestamps to ensure that only the most recent data is maintained across both systems.

      • Set up GET, PATCH, and POST requests with proper error handling to keep data consistent and secure.

  3. Security Best Practices:

    • Learn how to configure Access Control Lists (ACLs) and OAuth settings to secure your APIs.

    • Understand how to apply IP restrictions and basic authentication to protect data transfers.

    • Use clear logging and error management techniques to troubleshoot integration issues effectively.

  4. Testing and Troubleshooting:

    • Gain hands-on experience with ServiceNow’s REST API Explorer and external tools like Postman.

    • Follow step-by-step instructions to test each endpoint and validate that your integration works as intended.

  5. Hands-On, Practical Learning:

    • Work on projects that mirror real ServiceNow challenges, ensuring you build skills that are directly applicable to your work.

    • Learn methods for updating integrations without disrupting live services.

About Your Instructor

I’m Lukasz Szumilas, a ServiceNow Developer and Consultant with real-world experience from companies like Accenture and Nelem Solutions. With over 8,600 followers on LinkedIn and more than 100 published articles, I bring simple, effective lessons based on practical challenges. I share my learnings to help you succeed in your ServiceNow career.

Why Enroll?

By the end of this course, you will have the confidence and skills to build and maintain robust integrations in ServiceNow. You will earn a certificate that confirms your expertise and be prepared to apply these techniques in real projects. Sign up today and take a big step forward in your ServiceNow career!

Who this course is for:

  • Are a ServiceNow Developer: Looking to add Scripted REST APIs and integrations to your skill set and work on advanced projects.
  • Work in IT: Whether you’re an admin, analyst, or IT specialist, and want to understand how to connect ServiceNow with other systems effectively.
  • Are New to REST APIs: If you’ve heard about APIs but never had the chance to use them in a real project, this course will guide you through the process.
  • Enjoy Hands-On Learning: If you prefer practical examples and step-by-step instructions instead of abstract theory, this course is perfect for you.