sys_rest_message Table

Table Reference/sys_rest_message

The sys_rest_message table stores outbound REST API integration configurations managed in the Integration module. Developers script against this table when dynamically creating or modifying REST message definitions that work with the RESTMessageV2 class.

What This Table Is

The sys_rest_message table stores the configuration data for outbound REST API integrations. Each record represents a complete REST message definition including endpoint URLs, authentication settings, HTTP headers, and connection parameters. These configurations are consumed by the RESTMessageV2 scripting class to make actual HTTP requests to external systems.

This table belongs to the Integration module and supports ServiceNow's outbound integration capabilities. Unlike inbound REST APIs (which use scripted REST resources), these records define how ServiceNow calls external services. The data flows from configuration → script execution → external API call, making this table the foundation for most enterprise integrations that push data out of ServiceNow.

The table does not extend any parent table and has one important child table: sys_rest_message_fn stores the individual HTTP methods (GET, POST, PUT, DELETE) for each REST message. A single REST message can have multiple HTTP methods, each with different parameters, request body templates, and response processing logic.

Most enterprises have 50-200 REST message records depending on their integration footprint. Performance is generally not a concern with this table since it's configuration data that's read during script execution rather than queried frequently. However, the actual REST calls configured here can become performance bottlenecks if not properly implemented with timeouts and error handling.

When You'll Script Against This Table

Direct queries against sys_rest_message are uncommon. Most developers work with this table indirectly through the RESTMessageV2 class, which automatically loads the configuration when you instantiate it with a REST message name. You'll typically script against this table in Business Rules, Script Includes, Scheduled Jobs, and Integration Hub flows when building dynamic integrations or managing REST message configurations programmatically.

Access to this table requires the rest_service role for read access and admin or rest_service_admin for write operations. The actual execution of REST messages through RESTMessageV2 can be done with lower privileges, but creating or modifying configurations requires elevated access.

Creating REST message configurations programmatically for multi-tenant integrations
Dynamically updating endpoint URLs based on environment (dev, test, prod)
Bulk updating authentication credentials across multiple REST messages
Auditing REST message usage and identifying unused integrations
Cloning existing REST messages with modified endpoints for testing
Setting up conditional REST endpoints based on record data or business logic
Implementing REST message configuration as code for deployment automation

Table Gotchas

⚠️

The endpoint field can contain variable substitutions like ${variable_name} but these are resolved at execution time, not when you query the table. The raw endpoint value in the database will still contain the unresolved variables.

⚠️

Authentication settings in the authentication_type and auth_profile_id fields are tightly coupled. Changing authentication_type without updating the corresponding auth_profile_id will cause REST calls to fail silently or with cryptic authentication errors.

The name field must be unique and is case-sensitive. Creating duplicate names will cause RESTMessageV2 to load the first match it finds, which may not be the one you expect.
REST message records are cached aggressively. Changes to endpoint or use_mid_server may not take effect immediately in running scripts. Restart the glide service or wait for cache expiration.
The accessible_from field controls scoped application access. Setting this to 'package_private' will prevent cross-scope REST message usage even if the calling script has elevated privileges.
Deleting a REST message record does not cascade delete its related sys_rest_message_fn records automatically in all versions. Always clean up HTTP method records manually to avoid orphaned data.

⚠️

Never query this table in loops or high-frequency operations. Use RESTMessageV2 constructor caching instead, or load configurations once and reuse them across multiple operations.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sys_rest_message_fn table is the most important related table, storing individual HTTP methods for each REST message. You'll often join these tables when analyzing REST message configurations or building dynamic integration logic that needs to inspect available methods and their parameters.

Authentication-related queries frequently join with sys_auth_profile_basic, sys_auth_profile_oauth2, and other auth profile tables based on the authentication_type value. The ecc_queue table becomes relevant when use_mid_server is true, as REST calls are queued through the MID Server infrastructure. For audit and troubleshooting, sys_log often contains REST message execution logs that reference the message name.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Name	Unique identifier used in RESTMessageV2 constructor. Must be unique and case-sensitive across all REST messages.
endpoint	string	Endpoint	Base URL for the REST service. Can contain variable substitutions like ${instance} that are resolved at runtime.
description	string	Description	Documentation for the REST message purpose and usage. Critical for maintaining enterprise integrations.
authentication_type	choice	Authentication Type	Defines auth method: inherit_from_parent, basic, oauth2, or no_authentication. Must match corresponding auth_profile_id type.
auth_profile_id	reference	Authentication Profile	References specific auth profile table based on authentication_type. Points to sys_auth_profile_basic, sys_auth_profile_oauth2, etc.
use_mid_server	boolean	Use MID Server	Routes REST calls through MID Server instead of direct ServiceNow outbound. Required for internal network endpoints.
mid_server	reference	MID Server	References ecc_agent table for specific MID Server selection. Only relevant when use_mid_server is true.
active	boolean	Active	Controls whether REST message can be executed. Inactive messages will cause RESTMessageV2 constructor to fail.
accessible_from	choice	Accessible From	Scoped application access control: all, package_private, or this_application_scope_only. Affects cross-scope usage.
application	reference	Application	References sys_app table for scoped application ownership. Determines default access permissions and update set scope.
rest_endpoint	string	REST Endpoint	Alternative endpoint configuration that can override the primary endpoint field in specific contexts.
protocol_name	choice	Protocol Name	HTTP protocol version preference. Usually 'rest' but can affect header handling and connection behavior.
lock_version	integer	Lock Version	Version control for concurrent updates. Prevents conflicts when multiple developers modify the same REST message.
default_request_headers	string	Default Request Headers	JSON string of headers applied to all HTTP methods. Parsed at runtime and merged with method-specific headers.
use_basic_auth	boolean	Use Basic Authentication	Legacy field for basic auth. Superseded by authentication_type and auth_profile_id but still affects some configurations.

Common Queries

Get all active REST messages

// Basic query every developer starts with
var gr = new GlideRecord('sys_rest_message');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('Active REST Message: ' + gr.getValue('name'));
    gs.info('Endpoint: ' + gr.getValue('endpoint'));
}

// Returns all active REST message configurations
// Use this to audit available integrations

Find REST messages by authentication type and application scope

// Filter by auth method and scoped app
var gr = new GlideRecord('sys_rest_message');
gr.addQuery('active', true);
gr.addQuery('authentication_type', 'oauth2');
gr.addQuery('application.name', 'My Custom App');
gr.query();

while (gr.next()) {
    gs.info('OAuth2 REST Message: ' + gr.getDisplayValue('name'));
    gs.info('Auth Profile: ' + gr.getDisplayValue('auth_profile_id'));
}

Find REST messages calling specific external domains

// Real-world scenario: audit integrations to external systems
var gr = new GlideRecord('sys_rest_message');
gr.addQuery('endpoint', 'CONTAINS', 'api.salesforce.com');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('Salesforce Integration: ' + gr.getValue('name'));
    gs.info('Uses MID Server: ' + gr.getValue('use_mid_server'));
    gs.info('Auth Type: ' + gr.getValue('authentication_type'));
}

// Critical for security audits and vendor management

Count REST messages by authentication type

// Aggregate count for integration architecture analysis
var ga = new GlideAggregate('sys_rest_message');
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.groupBy('authentication_type');
ga.query();

while (ga.next()) {
    var authType = ga.getValue('authentication_type');
    var count = ga.getAggregate('COUNT');
    gs.info('Auth Type: ' + authType + ', Count: ' + count);
}

Wrong way vs right way to load REST message configuration

// WRONG: Querying sys_rest_message directly in business logic
var gr = new GlideRecord('sys_rest_message');
gr.addQuery('name', 'MyRestMessage');
gr.query();
if (gr.next()) {
    var endpoint = gr.getValue('endpoint'); // Missing variable substitution
}

// RIGHT: Use RESTMessageV2 class instead
var rm = new sn_ws.RESTMessageV2('MyRestMessage', 'get');
// Handles caching, variable substitution, and auth automatically

Related Tables

ecc_queue

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue