Integration Patterns & REST/SOAP | ServiceNow CSA Part 5

Section 1

ServiceNow Integration Overview

ServiceNow acts as both a consumer and a provider of integrations. Understanding the direction of data flow is the foundation for all integration questions on the CSA exam.

Integration Directions

⬇️

Inbound Integration

An external system sends data into ServiceNow to create, read, or update records.

Example: A monitoring tool creates an Incident record in ServiceNow when an alert fires.

⬆️

Outbound Integration

ServiceNow sends data to an external system — to notify, synchronize, or trigger a workflow.

Example: When an Incident is resolved, ServiceNow posts a message to a Slack channel.

🔄

Bidirectional Integration

Data flows both ways between ServiceNow and an external system — records stay synchronized in real time or near-real time.

Example: ServiceNow and Jira sync ticket status changes in both directions.

Synchronous vs. Asynchronous Integration

Aspect	Synchronous	Asynchronous
Behavior	Caller waits for a response before continuing	Caller sends the request and moves on; response arrives later
Use case	Real-time data lookups, immediate confirmations	Long-running operations, bulk processing, notifications
Example	REST GET to look up a user record	Email notification triggered by a Business Rule
Risk	Can block execution if the external system is slow	No immediate error feedback; harder to debug

Integration Hub

Integration Hub is ServiceNow's no-code/low-code integration platform built on Flow Designer. It provides pre-built connectors called spokes that abstract away the complexity of building integrations from scratch.

Key Concept: Integration Hub allows non-developers to connect ServiceNow with external systems (Slack, Jira, AWS, Salesforce, etc.) using drag-and-drop steps in Flow Designer — no scripting required for standard integrations. Many spokes require the IntegrationHub license (not included in base ServiceNow).

Section 2

REST API — Inbound Integrations

The Table API is the most common and important inbound integration method in ServiceNow. It allows any external system to perform full CRUD operations on any ServiceNow table via standard HTTP requests.

Table API

Table API Endpoint Pattern:

https://<instance>.service-now.com/api/now/table/{tableName}

Replace {tableName} with the actual table name, for example incident, sc_request, or any custom table name.

HTTP Methods and Their Operations

Method	Operation	Example URL	Notes
GET	Read / query records	`/api/now/table/incident`	Supports query params: `sysparm_query`, `sysparm_limit`, `sysparm_fields`
POST	Create a new record	`/api/now/table/incident`	Body contains JSON field values; returns the created record's sys_id
PUT	Full update (replace record)	`/api/now/table/incident/{sys_id}`	Replaces all field values; omitted fields may be cleared
PATCH	Partial update	`/api/now/table/incident/{sys_id}`	Updates only the fields provided in the request body
DELETE	Delete a record	`/api/now/table/incident/{sys_id}`	Permanently removes the record; requires delete ACL permission

Authentication Methods

Basic Authentication

Username and password encoded in the HTTP header. Simple to implement but less secure — credentials sent with every request.

Use for: development/testing environments, simple integrations where security is not critical.

OAuth 2.0

Token-based authentication. The client exchanges credentials for an access token; subsequent requests use only the token. Preferred method for production integrations.

Tokens have expiry times and can be revoked without changing credentials.

API Key

A static key sent in the request header. Simpler than OAuth, more secure than Basic Auth. Appropriate for server-to-server integrations with controlled environments.

Configure in: System OAuth > Application Registry.

Exam Must-Know: The Table API is the most common inbound integration method for the CSA exam. Know the endpoint pattern, the five HTTP methods and what each does, and that OAuth 2.0 is the preferred authentication method for modern integrations.

sys_rest_message — Outbound REST Configuration Table

While the Table API handles inbound calls (external systems calling ServiceNow), outbound REST calls made by ServiceNow are configured in the sys_rest_message table. This distinction is important for the exam.

Section 3

REST Message — Outbound Integrations

When ServiceNow needs to call an external REST API, the configuration is stored in the sys_rest_message table. This is the outbound counterpart to the inbound Table API.

Configuration Components

REST Message Record

The parent record stored in sys_rest_message. Defines the base endpoint URL, default authentication, and headers for a target external service.

Navigate to: System Web Services > Outbound > REST Message

REST Message Functions

Child records under a REST Message. Each function represents a specific HTTP method call (GET, POST, PUT, etc.) with its own endpoint path, headers, and body template.

One REST Message can have multiple functions for different operations on the same service.

Authentication Profiles

Reusable authentication configurations referenced by REST Messages. Supports Basic, OAuth 2.0, and mutual authentication profiles stored separately for reuse across multiple integrations.

Testing Outbound REST

How to Test: Open the REST Message record → select a function → click the Test related link. ServiceNow sends a live HTTP request to the external endpoint and displays the response code, headers, and body directly in the platform. No scripting required to test connectivity.

Where REST Messages Are Called From

Once configured, REST Message functions can be invoked from any server-side script using the RESTMessageV2 API:

// Called from Business Rule, Script Include, or Flow Designer
var rm = new sn_ws.RESTMessageV2('My External Service', 'post_incident');
rm.setStringParameterNoEscape('incident_number', current.number);
var response = rm.execute();
var statusCode = response.getStatusCode();
gs.info('External API returned: ' + statusCode);

Business Rules

Trigger on record insert/update

Script Includes

Reusable server-side library functions

Flow Designer

No-code Send REST Request step

Scheduled Scripts

Time-based background jobs

Section 4

SOAP Web Services

SOAP (Simple Object Access Protocol) is a legacy XML-based integration protocol. While REST has largely replaced SOAP for new integrations, many enterprise systems still use SOAP and the CSA exam tests awareness of it.

Inbound SOAP

Direct Web Service Access

Every ServiceNow table is automatically exposed as a SOAP web service. The WSDL (Web Services Description Language) document describes the available operations.

WSDL URL pattern:
https://<instance>.service-now.com/<table>.do?WSDL

sys_web_service Table

Stores inbound SOAP web service configurations. Allows customizing which operations are exposed and controlling access to the SOAP interface for a given table.

Navigate to: System Web Services > Inbound > Web Services

Outbound SOAP

Similar to outbound REST, outbound SOAP calls from ServiceNow are configured in the sys_soap_message table.

Aspect	Inbound SOAP	Outbound SOAP
Table	`sys_web_service`	`sys_soap_message`
Direction	External system → ServiceNow	ServiceNow → External system
WSDL	ServiceNow publishes WSDL at `table.do?WSDL`	Import WSDL from external service to generate message
Protocol	XML over HTTP/HTTPS	XML over HTTP/HTTPS

WSDL Definition: WSDL stands for Web Services Description Language. It is an XML document that describes a SOAP web service — what operations are available, what parameters each operation takes, and what responses are returned. Think of it as the "API documentation" for a SOAP service.

REST vs. SOAP — When to Use Which: For new integrations, always prefer REST — it is simpler, lighter, and supported by all modern systems. SOAP is used when integrating with legacy enterprise systems (SAP, older ERP platforms, mainframe-adjacent services) that only expose SOAP endpoints.

Section 5

Integration Hub

Integration Hub is a Flow Designer-based integration platform that provides pre-built connectors (spokes) for popular external systems. It is designed for no-code integration — connecting systems without writing scripts.

Key Concepts

🔌

Spokes

Pre-built integration connectors for specific external systems. Each spoke bundles all the actions needed to interact with that system.

Examples: Slack Spoke, Jira Spoke, AWS Spoke, Salesforce Spoke, Microsoft Teams Spoke

⚙️

Steps (Actions)

Individual operations within a spoke. Dragged into a Flow Designer flow to perform specific tasks.

Common steps: Send REST Request, Look Up Record, Create Record, Post Message to Slack

📋

Action Designer

The tool used to build custom spokes and actions when pre-built spokes do not cover your specific external system or use case.

Navigate to: Flow Designer > Action Designer

Integration Hub vs. Base Platform

Critical Exam Point: Integration Hub is NOT included in the base ServiceNow platform license. It requires a separate IntegrationHub license to access most spokes. The base platform includes Flow Designer, but the spoke library (Slack, Jira, AWS, etc.) requires the add-on license.

Feature	Base Platform	IntegrationHub License
Flow Designer	Included	Included
Basic REST/SOAP steps	Included (Send REST Request)	Included
Pre-built spokes	Limited or none	Full spoke library (Slack, Jira, AWS, etc.)
Action Designer	Included	Included

Section 6

Scripted REST APIs

Scripted REST APIs allow administrators to create custom REST endpoints on the ServiceNow instance — exposing custom business logic as a REST service that external systems can call.

When to Use Scripted REST APIs

The built-in Table API covers most inbound integration scenarios, but Scripted REST APIs are needed when:

The required logic does not map directly to a single table (e.g., aggregated data from multiple tables)
You need to expose a specific business process (not raw CRUD) to an external system
Custom authentication or response formatting is required
You want to hide the underlying table structure from external callers

Configuration

sys_ws_definition Table

Stores Scripted REST API definitions. Each record defines a custom API namespace and base path.

Navigate to: System Web Services > Scripted REST APIs

Resources

Child records under a Scripted REST API. Each resource defines the HTTP method, URL path, and the server-side script that processes the request and builds the response.

Request/Response Objects

Within the script, use request to read headers, query params, and body; use response to set the status code, headers, and response body.

// Example Scripted REST API resource script
(function process(request, response) {
  var incidentNum = request.queryParams.number[0];
  var gr = new GlideRecord('incident');
  gr.addQuery('number', incidentNum);
  gr.query();
  if (gr.next()) {
    response.setStatus(200);
    response.setContentType('application/json');
    response.setBody(JSON.stringify({
      number: gr.number.toString(),
      state: gr.state.toString(),
      short_description: gr.short_description.toString()
    }));
  } else {
    response.setStatus(404);
    response.setBody(JSON.stringify({ error: 'Incident not found' }));
  }
})(request, response);

Table API vs. Scripted REST: Use the Table API for standard CRUD operations on a single table. Use Scripted REST APIs when you need custom logic, aggregated data, or a specific interface contract that does not match standard table operations.

Section 7

Email Integration

Email is a foundational integration channel in ServiceNow — used both for receiving requests and for sending notifications. Email integration is configured at the instance level and operates independently of REST/SOAP.

Inbound Email

Inbound Email Actions

Rules that process incoming emails and take automated actions — create records, update existing records, add work notes, or trigger workflows based on email content.

Navigate to: System Policy > Email > Inbound Actions

Watermark Matching

ServiceNow embeds a unique watermark in outbound emails. When a reply arrives, the watermark is used to match the reply to the correct ServiceNow record and automatically update it.

POP3 / IMAP Configuration

ServiceNow polls an inbound email mailbox using POP3 or IMAP. Emails retrieved from this mailbox are processed by Inbound Email Actions.

Navigate to: System Mailboxes > Inbound

Outbound Email

Notification Rules

Trigger-based rules that automatically send emails when specific conditions are met on a record (e.g., Incident assigned, Priority changed to Critical).

Navigate to: System Notification > Notifications

Email Templates

Reusable HTML/text templates for email body content. Variables pull dynamic data from the triggering record (e.g., ${number}, ${short_description}).

SMTP Configuration

Outbound email is sent via SMTP. Configured at the instance level under System Mailboxes > Outbound. ServiceNow can use its own SMTP relay or a customer-provided mail server.

Section 8

MID Server

The Management, Instrumentation, and Discovery (MID) Server is a Java application that runs on a server within a customer's internal network. It acts as a secure bridge between the ServiceNow cloud instance and systems inside a private network that are not directly accessible from the internet.

When Is a MID Server Required?

JDBC Connections

Direct database connections (SQL Server, Oracle, MySQL) to internal databases. The MID Server executes the database queries on behalf of ServiceNow.

LDAP / Active Directory

User import and authentication against internal directory services that are not exposed to the internet.

Internal Network REST

Outbound REST calls to APIs hosted inside the corporate network (non-publicly accessible endpoints).

Discovery & CMDB

Network scanning and device discovery within internal subnets. The MID Server performs the scanning and reports findings back to ServiceNow.

Exam Must-Know — MID Server Triggers: A MID Server is required any time ServiceNow needs to communicate with a system that is inside a private/internal network and not reachable from the public internet. Memorize these specific cases: JDBC, LDAP, internal REST, and Discovery.

Section 9

Key Exam Facts & Traps

This section consolidates the highest-priority integration facts that appear on CSA exam questions.

Fact 1 — Table API is the most common inbound method: When an external system needs to create or update records in ServiceNow, the answer is almost always the Table API using REST. Endpoint: /api/now/table/{tableName}.

Fact 2 — Outbound REST lives in sys_rest_message: When ServiceNow needs to call an external REST API, the configuration is stored in the sys_rest_message table. Do not confuse this with the Table API (which handles inbound calls).

Fact 3 — OAuth 2.0 is the preferred auth: For modern integrations, OAuth 2.0 is the preferred authentication method. Basic Auth is acceptable for testing but not recommended for production. Know that OAuth uses access tokens, not raw credentials.

Fact 4 — MID Server = internal network access: If an exam question mentions connecting to an internal database, on-premises LDAP, or a REST API behind a firewall, the answer involves a MID Server. No MID Server = no connection to private network resources.

Fact 5 — IntegrationHub requires a license: Integration Hub (spokes) is NOT part of the base platform. The exam may try to trick you into thinking spokes are always available — they require a separate IntegrationHub license purchase.

Fact 6 — Scripted REST vs. Table API: The Table API handles standard CRUD on any table. Scripted REST APIs (sys_ws_definition) expose custom logic as a REST endpoint — use when the Table API is not sufficient for the required operation.

Fact 7 — WSDL = SOAP: WSDL (Web Services Description Language) is always associated with SOAP, not REST. If an exam question mentions WSDL, the integration is SOAP-based. WSDL is available at <table>.do?WSDL.

Integration Methods Quick Reference

Integration Type	Direction	Table / Location	Key Fact
Table API (REST)	Inbound	`/api/now/table/{table}`	Most common inbound method; full CRUD
REST Message	Outbound	`sys_rest_message`	Configured outbound REST calls from ServiceNow
SOAP (Inbound)	Inbound	`sys_web_service`	Legacy; WSDL at `table.do?WSDL`
SOAP Message	Outbound	`sys_soap_message`	Configured outbound SOAP calls from ServiceNow
Scripted REST API	Inbound	`sys_ws_definition`	Custom endpoints; use when Table API insufficient
Integration Hub	Outbound / Both	Flow Designer > Spokes	No-code; requires IntegrationHub license
Email (Inbound)	Inbound	System Policy > Email > Inbound Actions	Creates/updates records from email; POP3/IMAP
Email (Outbound)	Outbound	System Notification > Notifications	Notification rules; SMTP; email templates
MID Server	Bridge	On-premises agent	Required for JDBC, LDAP, internal REST, Discovery