---
sourceDocument: Yokohama API Reference
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/api-reference

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama API Reference

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# REST APIs

# REST APIs {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 14 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of REST APIs

ServiceNow provides a comprehensive set of REST APIs based on the REST architecture, enabling stateless communication between client applications and ServiceNow instances.
These APIs allow customers to perform create, read, update, and delete (CRUD) operations on ServiceNow tables, interact with MetricBase time series data, and more.
REST APIs are enabled by default and follow standard protocols with additional custom parameters for enhanced functionality.
Show full answer Show less  

## Key Features

* **REST URI and Versioning:** URIs include optional version numbers to ensure integration stability across platform updates. If a version is not specified, the latest endpoint version is used.
* **Supported HTTP Methods:** GET, DELETE, HEAD, PATCH, POST, PUT with specific behaviors such as HEAD returning responses without bodies.
* **Data Formats and Headers:** Requests require proper Accept and Content-Type headers (typically application/json or application/xml). Missing headers cause errors.
* **Authentication and Security:** Supports basic authentication, OAuth, multi-factor authentication (MFA), and certificate-based authentication. Access is controlled by ACLs and REST API access policies that can restrict usage by IP, roles, and groups.
* **Custom Query Parameters:** Parameters like `sysparmlimit`, `sysparmoffset`, `sysparmfields`, `sysparmquery`, and `sysparminputdisplayvalue` enable filtering, pagination, field selection, and control over input value interpretation.
* **Dot-Walking Support:** Allows querying and retrieving related record data through dot notation in queries and field selections for richer data retrieval.
* **REST API Explorer:** A built-in tool for discovering endpoints, constructing requests, and generating sample code in multiple languages, requiring the `restapiexplorer` role.
* **CORS Support:** Enables configuration of cross-origin resource sharing rules to control which external domains can access REST APIs and which methods and headers are allowed.
* **Automated Testing:** The Automated Test Framework (ATF) supports inbound REST test steps to facilitate testing of custom REST APIs for upgrade safety and backward compatibility.
* **Example Client Applications:** Open-source sample REST client applications demonstrate integration patterns and provide starting points for customer implementations.

## Practical Considerations for Customers

* **API Security:** Always include proper authentication headers and ensure users have the necessary roles and ACL permissions to access APIs and data fields.
* **Handling Large Data Sets:** Use pagination parameters (`sysparmlimit` and `sysparmoffset`) to manage large result sets efficiently and avoid performance impacts.
* **Data Field Handling:** To clear a field value, send an empty string (except for choice fields). Currency fields return values converted to user locale but store inserted values as provided.
* **Display vs Actual Values:** By default, APIs process actual database values; set `sysparminputdisplayvalue=true` to work with display values, especially important for encrypted fields.
* **Error Handling:** Review HTTP response codes returned by REST calls to troubleshoot errors. Common codes include 400 for bad requests and 401 for authentication failures.
* **Session Debugging:** You can enable session debug logs in responses by including the `X-WantSessionDebugMessages` header to assist in troubleshooting inbound REST calls.
* **Public Table Access:** Tables can be made public with caution by adding them to the Public Pages table, but ACLs are still enforced by default; disabling ACLs is not recommended for security reasons.
* **Multi-Factor Authentication:** MFA is not required by default for REST API calls but can be configured for enhanced security. Responses vary based on MFA token validity.

## Additional Resources and Next Steps

* Use the REST API Explorer to build and test REST requests interactively within your instance.
* Leverage the Automated Test Framework to create regression tests for your custom REST APIs.
* Review example client applications to understand integration methods and accelerate development.
* Refer to REST API documentation for detailed information on endpoints, parameters, response codes, and security best practices.
* Consider configuring CORS rules to control cross-domain API access for web applications.
* Implement appropriate REST API access policies and ACLs to secure your APIs based on your organization's needs.  
REST (REpresentational State Transfer) is a simple stateless architecture that provides
standards between computer systems on the web, making it easier for them to communicate with each
other.
The ServiceNow AI Platform provides various REST APIs, which are active by default. These
APIs provide the ability to interact with various ServiceNow functionality
within your application. Such functionality includes the ability to perform create, read,
update, and delete (CRUD) operations on existing tables (Table API), insert
data into, retrieve information from, and run transforms against a MetricBase database
(MetricBase Time Series API, and many others.

For a list of available REST APIs, see [REST API reference](https://www.servicenow.com/docs/TAobmkBqHSgcySMDV9MoSw "Use REST interfaces to access data on your instance.").  
Note:  
You can view inbound API transactions in the Transaction logs. Use a link like the one below to view the transactions for the current day:

`https://<instancename>.service-now.com/syslog_transaction_list.do?sysparm_query=sys_created_onONToday%40javascript%3Ags.beginningOfToday()%40javascript%3Ags.endOfToday()%5Etype%3Drest`

## REST URI format and available parameters {#c_RESTAPI__section_rlc_q3b_zhb}

ServiceNow REST APIs follow standard
REST API protocol. They also provide "custom" URI and query parameters to ensure backwards
compatibility and provide additional functionality such as paginating long lists of results. The
following sections describe the functionality behind these custom parameters, which are all
optional.

## REST API versioning {#c_RESTAPI__section_orl_rm2_whb}

ServiceNow REST API URIs may include a
version number, such as /api/now/v1/table/{tableName}. Version numbers
identify the endpoint version that a URI accesses. By specifying a version number in your URIs,
you can ensure that future updates to the REST API do not negatively impact your integration.

URIs that do not specify a version number in the URI, such as
/api/now/table/{tableName}, use the latest REST endpoint for your instance
version.

## Supported HTTP request methods {#c_RESTAPI__supported_HTTP_methods}

* GET
* DELETE
* HEAD
* PATCH
* POST
* PUT
{#c_RESTAPI__ul_zlt_x2d_jlb}

For details on these methods, refer to the [RFC-2616
Hypertext Transfer Protocol](https://www.rfc-editor.org/rfc/rfc2616#page-51) document.  
Note:  
* You can use the HEAD methods in place of GET methods to return a response without a response body.
* You cannot pass multiple records in POST, PUT, and PATCH operations. If you do, only the first record is processed, the rest are ignored.
* You cannot use POST, PUT, and PATCH to insert or update records into a Database view, as Database views are read-only.
{#c_RESTAPI__ul_akw_c5y_gtb}

## Data format headers {#c_RESTAPI__section_uh3_fn2_whb}

REST APIs require the Accept and Content-Type
request headers for proper data formatting for requests that contain a request body or response
body. POST, PUT, PATCH, and DELETE operations require you to provide both headers. GET and HEAD
operations require only the Accept header. Failing to provide the required
headers results in a 400 Bad Request error.

For most ServiceNow REST APIs these
request headers support the following values:

* Accept: application/json, application/xml
* Content-Type: application/json, application/xml

{#c_RESTAPI__ul_cns_g2r_pp}

For the list of specific values supported by each endpoint, refer to the [REST API reference](https://www.servicenow.com/docs/TAobmkBqHSgcySMDV9MoSw "Use REST interfaces to access data on your instance.").

## Other headers {#c_RESTAPI__section_ay1_3n2_whb}

All requests may contain an authentication header that specifies the user credentials to use
for authentication.

You can also override HTTP methods, such as GET or POST, by setting the
X-http-method-override header.

## Special data handling {#c_RESTAPI__section_q1p_krf_htb}

The following describes some of the data handling nuances within the REST API.

* How to clear a data field: Except for choice fields, you can pass an empty value in the parameter to clear the value in the database. For example, sending `{"short
  description":""}` clears the short_description field for the specified record.
* How currency fields are handled: Returned currency values are converted to the local currency based on the user's locale. When inserting data, no conversion is performed. This behavior applies to fields of the types `Currency` or `Price`.

  For example, if a user in the UK locale queries records with
  currency values in USD, the returned values are converted to GBP. However, if this user adds a
  new record with the currency field value in GBP, the value is stored in GBP without being
  converted to USD. This GBP value appears in USD if queried by a user in the US
  locale.
* UI data display versus values passed in a REST endpoint: The UI shows the database [display value](https://www.servicenow.com/docs/access?context=c_DisplayValues&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US), which is manipulated data. A REST endpoint, by default, inserts and updates the actual values, which can be different from the display value. You can force a REST endpoint to treat passed values as display values by setting the [sysparm_input_display_value](https://www.servicenow.com/docs/aXidvjgEVmS~V~ZL0h85lQ#c_RESTAPI__REST-sysparm_input_display_value-row) request parameter to true.
{#c_RESTAPI__ul_xj3_trf_htb}

## Custom query parameters {#c_RESTAPI__section_m4z_jnb_zhb}

The ServiceNow REST APIs use the
following query parameters across many of the available APIs, providing consistent behavior
across the APIs. Use these parameters to paginate large record sets, filter results, and
restrict the number of records returned in a single query.
{#c_RESTAPI__table_z1v_znb_zhb__entry__2}{#c_RESTAPI__sysparm-limit-RESTAPI}{#c_RESTAPI__sysparm_fields_entry-RESTAPI}{#c_RESTAPI__entry-sysparm_input_display_value-REST_API}{#c_RESTAPI__sysparm_offset-ph-RESTAPI}{#c_RESTAPI__sysparm-query-RESTAPI}{#c_RESTAPI__sysparm_view-entry-RESTAPI}

|   |   |
|-|-|
| sysparm_limit | Maximum number of records to return. For requests that exceed this number of records, use the sysparm_offset parameter to paginate record retrieval. This limit is applied before ACL evaluation. If no records return, including records you have access to, rearrange the record order so records you have access to return first. Note: Unusually large sysparm_limit values can impact system performance. Data type: Number Default: 10000 |
| sysparm_fields | Comma-separated list of fields to return in the response. Invalid fields are ignored. Data type: String Default: Return all fields. |
| sysparm_input_display_value | Flag that indicates whether to set field values using the display value or the actual value. Depending on the different types of fields, the endpoint may manipulate the passed in display values to store the proper values in the database. For example, if you send the display name for a reference field, the endpoint stores the sys_id for that value in the database. For date and time fields, when this parameter is true, the date and time value is adjusted for the current user's timezone. When false, the date and time value is inserted using the GMT timezone. Valid values: * true: Treats input values as display values and they are manipulated so they are stored properly in the database. * false: Treats input values as actual values and stores them in the database without manipulation. {#c_RESTAPI__ul_shq_cfx_pp} Data type: Boolean Default: false - This matches the data type that is returned during data retrieval (GET methods), which is the actual values. Note: To set the value of an encrypted field, you must set this parameter to <kbd class="ph userinput">true</kbd>. If this parameter is not set to true, values submitted to encrypted fields are not saved. Additionally, the requesting user must have the appropriate encryption context prior to submitting the request. Encrypted fields are hidden for users without the appropriate encryption context. For more information on field encryption see [Encryption](https://www.servicenow.com/docs/access?context=encryption-landing&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). |
| sysparm_offset | Starting record index for which to begin retrieving records. Use this value to paginate record retrieval. This functionality enables the retrieval of all records, regardless of the number of records, in small manageable chunks. For example, the first time you call this endpoint, sysparm_offset is set to "0". To simply page through all available records, use `sysparm_offset=sysparm_offset+sysparm_limit`, until you reach the end of all records.{#c_RESTAPI__sysparm_offset-p-RESTAPI} Don't pass a negative number in the sysparm_offset parameter. Data type: Number Default: 0 |
| sysparm_query | [Encoded query](https://www.servicenow.com/docs/access?context=c_EncodedQueryStrings&version=yokohama&pubname=yokohama-platform-user-interface&ft:locale=en-US) used to filter the result set. You can use a UI filter to obtain a properly encoded query. Syntax: `sysparm_query=<col_name><operator><value>`. * \<col_name\>: Name of the table column to filter against. * \<operator\>: Supports the following values: * =: Exactly matches \<value\>. * !=: Does not match \<value\>. * \^: Logically AND multiple query statements. * \^OR: Logically OR multiple query statements. * LIKE: \<col_name\> contains the specified string. Only works for \<col_name\> fields whose data type is string. * STARTSWITH: \<col_name\> starts with the specified string. Only works for \<col_name\> fields whose data type is string. * ENDSWITH: \<col_name\> ends with the specified string. Only works for \<col_name\> fields whose data type is string. {#c_RESTAPI__ul_bgf_5vz_mlb} \<value\>: Value to match against. {#c_RESTAPI__ul_g2p_svz_mlb}For more operators, see [Operators available for filters and queries](https://www.servicenow.com/docs/access?context=r_OpAvailableFiltersQueries&version=yokohama&pubname=yokohama-platform-user-interface&ft:locale=en-US). All parameters are case-sensitive. Queries can contain more than one entry, such as sysparm_query=\<col_name\>\<operator\>\<value\>\[\<operator\>\<col_name\>\<operator\>\<value\>\]. For example: `(sysparm_query=caller_id=javascript:gs.getUserID()^active=true)` Encoded queries also support order by functionality. To sort responses based on certain fields, use the `ORDERBY` and `ORDERBYDESC` clauses in sysparm_query. Syntax: * `ORDERBY<col_name>` * `ORDERBYDESC<col_name>` {#c_RESTAPI__ul_sq4_rc1_nlb} For example: `sysparm_query=active=true^ORDERBYnumber^ORDERBYDESCcategory` This query filters all active records and orders the results in ascending order by number, and then in descending order by category. If part of the query is invalid, such as by specifying an invalid field name, the instance ignores the invalid part. It then returns rows using only the valid portion of the query. You can control this behavior using the property glide.invalid_query.returns_no_rows. Set this property to true to return no rows on an invalid query. Note: The glide.invalid_query.returns_no_rows property controls the behavior of all queries across the instance, such as in lists, scripts (GlideRecord.query()), and web service APIs. Data type: String |
| sysparm_view | UI view for which to render the data. Determines the fields returned in the response. Valid values: * desktop * mobile * both {#c_RESTAPI__ul_wr5_5xl_tgb} If you also specify the sysparm_fields parameter, it takes precedent. Data type: String |
[ ]

{#c_RESTAPI__table_z1v_znb_zhb}

## Dot-walking in REST API requests {#c_RESTAPI__section_k5v_sr1_xhb}

You can use dot-walking when specifying the sysparm_query or
sysparm_fields parameters in requests to REST APIs that support those
parameters.  
Note:  
The Import Set API does not support dot-walking.

## Dot-walking in sysparm_query {#c_RESTAPI__section_owg_vr1_xhb}

You can filter queries using related record values by dot-walking in the
sysparm_query parameter. For example, you can retrieve all incident
records where the incident Company has a specific Stock symbol value.

https://\<instance\>.service-now.com/api/now/table/incident?sysparm_query=company.stock_symbol=NYX

## Dot-walking in sysparm_fields {#c_RESTAPI__section_ufb_wr1_xhb}

You can view field values from multiple tables by dot-walking in the
sysparm_fields parameter. For example, you can retrieve the
Name, Sys_id, and
Department of each user that has certain roles, as well as the role
Name.

The request runs on the User Roles \[sys_user_has_role\] table which defines a many-to-many
relationship between users and roles. The response includes field values from the User
\[sys_user\] and Roles \[sys_user_role\] tables.

https://\<instance\>.service-now.com/api/now/table/sys_user_has_role?sysparm_fields=role%2Crole.name%2Cuser%2Cuser.name%2Cuser.sys_id%2Cuser.department\&sysparm_query=role%3D3d43716d0f6002003a2d47bce1050e0d%5EORrole%3Dac73b52d0f6002003a2d47bce1050eec\&sysparm_display_value=true

    {
    "result": [
      {
       "user.name": "Fred Johnson",
       "user.sys_id": "f5a3716d0f6002003a2d47bce1050ed4",
       "role.name": "support",
       "user.department": {
          "display_value": "Accounting",
          "link": "https://<instance>.service-now.com/api/now/table/cmn_department/5b3b13530f58c2003a2d47bce1050e96"
        },
       "role": {
          "display_value": "support",
          "link": "https://<instance>.service-now.com/api/now/table/sys_user_role/3d43716d0f6002003a2d47bce1050e0d"
        },
       "user": {
          "display_value": "Fred Johnson",
          "link": "https://<instance>.service-now.com/api/now/table/sys_user/f5a3716d0f6002003a2d47bce1050ed4"
        }
      },
      {
       "user.name": "Fred Johnson",
       "user.sys_id": "f5a3716d0f6002003a2d47bce1050ed4",
       "role.name": "asset_mgmt",
          "user.department": {
          "display_value": "Accounting",
          "link": "https://<instance>.service-now.com/api/now/table/cmn_department/5b3b13530f58c2003a2d47bce1050e96"
         },
        "role": {
           "display_value": "asset_mgmt",
           "link": "https://<instance>.service-now.com/api/now/table/sys_user_role/ac73b52d0f6002003a2d47bce1050eec"
          },
        "user": {
           "display_value": "Fred Johnson",
           "link": "https://<instance>.service-now.com/api/now/table/sys_user/f5a3716d0f6002003a2d47bce1050ed4"
           }
        }
      ]
    }

## REST API HTTP response codes {#c_RESTAPI__section_p5z_c42_whb}

Calls made to REST endpoints return HTTP response codes. You can use these response codes to
ensure that the REST API executed properly. If it did not, the endpoint returns an error
response code. Use the information in the error response to troubleshoot issues with your call
format. For a list of standard response codes that an endpoint may return, see [REST API HTTP response codes](https://www.servicenow.com/docs/MWP_rWcHNMeh4T87kf2~mA "REST messages sent to an instance return a specific HTTP response code."). For the list
of response codes returned by a specific ServiceNow REST API, see the [REST API reference](https://www.servicenow.com/docs/TAobmkBqHSgcySMDV9MoSw "Use REST interfaces to access data on your instance.").

## REST API security {#c_RESTAPI__section_mm2_3l2_whb}

By default, ServiceNow REST APIs use basic authentication or OAuth to
authorize user access to REST APIs/endpoints. You can also configure your instance to use [multi-factor
authentication](https://www.servicenow.com/docs/aXidvjgEVmS~V~ZL0h85lQ#c_RESTAPI__multi-factor-auth-inbound-REST) to access REST APIs.

The user ID that you specify in a REST endpoint call is subject to access control in the same
way as an interactive user. Each request requires the proper authentication information, such as
user name and password. Ensure that each endpoint request includes an Authorization header with
sufficient credentials to access the endpoint.

ServiceNow REST APIs also support
cookies that enable binding to the existing session.

To use the certificate to call the API and information on mutual authentication, see [Certificate-based authentication](https://www.servicenow.com/docs/access?context=certificate-based-authentication&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).

REST API access policies with the filter criterias such as IP, role, group and restrict the scope of API you can use the [REST API Auth Scope](https://www.servicenow.com/docs/access?context=rest-api-auth-scope&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). To know more about REST API access policy, see [REST API access policies](https://www.servicenow.com/docs/access?context=inbound-authentication-profile&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).

You can craft one single policy to block the incoming request, at a global REST API level by using the REST API Access policy from outside trusted network and at a basic REST authentication levels.

## REST API roles {#c_RESTAPI__section_iwr_fm2_whb}

In addition to user authentication, each REST endpoint can have different requirements for the
roles required to access the endpoint. Some require the admin role and others require API
specific roles. Role requirements are specified in the access control list (ACL) associated with
the REST API/endpoint. For specifics on the valid roles for each REST API/endpoint, refer to the
[REST API reference](https://www.servicenow.com/docs/TAobmkBqHSgcySMDV9MoSw "Use REST interfaces to access data on your instance.") or locate the
associated ACL for the API/endpoint within an instance through System Security \> Access Control (ACL).

## REST API ACLs {#c_RESTAPI__section_owx_4r2_nbb}

REST API ACLs define criteria, such as the roles needed and conditions that a user must meet
to access a ServiceNow REST API or endpoint. A single ACL may be defined
for an entire REST API, such as the Table API and Attachment API ACLs, or for an individual
endpoint, such as the clotho_rest_put ACL that only applies to MetricBase PUT
methods.

The following ServiceNow REST API ACLs
are available in the base system but are deactivated by default. All other ServiceNow REST API ACLs are active by
default.

* Table API
* Aggregate API
* Import Set API
* Attachment API

{#c_RESTAPI__ul_wws_wr2_nbb}

For additional information on ACLs, see [Access control list rules](https://www.servicenow.com/docs/access?context=access-control-rules&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).  
Important:  
You should never modify the names of REST API ACLs.

## REST API table access {#c_RESTAPI__section_l5h_rr2_whb}

By default, all tables, including base system tables, global tables, and scoped tables are
accessible through web services. You must fulfill any web service security requirements, such as
basic authentication and ACLs to access tables through web services. Fields for which the
calling entity does not have rights to because of ACLs are not returned in a REST query
response.

To allow access to tables without any authentication or authorization, add the table name to the Public Pages \[sys_public\] table with a status of Active. The REST interface still enforces any defined ACLs
on associated tables. If ACL enforcement is not the desired behavior, you must deactivate the ACLs on the tables. However, making your APIs public is not suggested because doing so allows the public access to update data in the
instance.

You can also control direct web service access to tables using the Allow access to this table via web services check box on the table application access settings. You
must select this check box to enable web service interaction with the table.  
Note:  
The application access fields controlling CRUD operations, such as Can read or Can create do not apply to web service requests.

## Multi-factor authentication for inbound REST {#c_RESTAPI__multi-factor-auth-inbound-REST}

From Yokohama release, Multi-factor authentication (MFA) is not required by default for REST API authentication using Basic Authentication. To know more, see this [KB article](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1745551).

## Multi-factor authentication REST responses {#c_RESTAPI__section_dkm_vx1_xhb}

The response to an MFA authentication request varies depending on the validity of the provided
credentials and MFA token.
{#c_RESTAPI__table_btf_ylc_55__entry__2}

| Result | Description |
|-|-|
| Basic auth credentials and MFA token are valid | User is authenticated and the session created. The request is processed normally. |
| Basic auth credentials are valid but MFA token is invalid or missing | Response returns error 401. The response includes the X-MFA_TOKEN header with the value invalid. |
| Basic auth credentials are invalid | Response returns error 401. The X-MFA_TOKEN header is not included in the response. |
[Table 1. Responses]

{#c_RESTAPI__table_btf_ylc_55}

## REST API CORS support {#c_RESTAPI__section_hpl_csl_whb}

The REST API supports cross-origin resource sharing (CORS) security. CORS support allows you
to define which domains can access each REST API. By defining a CORS rule for a domain, you can
allow cross-origin requests from that domain. Cross-origin requests cannot be made from domains
without a CORS rule.  
Note:  
CORS support applies only to REST APIs, including scripted REST web services. Other web service APIs, such as the SOAP API, do not support CORS.

You can configure CORS to allow access to only certain APIs/endpoints, HTTP methods, and
headers from other domains. For example, you can limit requests to the Table
API from a specific domain to allow only GET operations.

To view the CORS rules defined on your instance, navigate to System Web ServicesCORS Rules.

You can disable CORS support for an instance by setting the
glide.rest.cors.enabled property to false. When
false, no CORS evaluation is performed on incoming REST requests. This
property is true by default.

## REST API Explorer {#c_RESTAPI__section_y4h_5n1_xhb}

The REST API Explorer is a ServiceNow
tool that uses information from your instance to provide a list of endpoints, methods, and
variables that you can use to build and send REST requests.

After you build the request, the REST API Explorer provides code samples in multiple
programming languages that you can use to initiate the request, and detailed request and
response information.

To access the REST API Explorer, in your instance, navigate to System Web ServicesREST API Explorer. You must have the rest_api_explorer role to access the REST API Explorer. For
additional information, see [Use the REST API Explorer](https://www.servicenow.com/docs/VV5d3pcHRv4pFxM~yEJQZA "In this tutorial you will use the REST API Explorer to test the ServiceNow REST APIs.").  
Warning:  
The REST API Explorer interacts with data on the current instance. Use caution when working with requests that create, edit, or delete data on a production instance.

## Automated Test Framework support {#c_RESTAPI__section_pcq_lxp_g3b}

The Automated Test Framework (ATF) supports inbound REST test steps. You can create automated
tests for custom inbound REST APIs that you create. Creating tests for your custom REST APIs
simplifies upgrade testing, and makes it possible to verify that modifications to a REST API are
backward compatible.

## Example REST client applications {#c_RESTAPI__section_jhj_qw1_xhb}

Several example REST client applications and source code are available to demonstrate
integrations using REST web services. The example REST client applications demonstrate how to
use the ServiceNow REST API with an
external application, such as a NodeJS or iOS application.  
Important:  
These applications are provided only as a demonstration of the REST functionality and are not officially supported.

The examples are open source and available to the community. You can use these example
applications to help familiarize yourself with the REST functionality, or use them as a starting
point to create your own REST client applications.

Users with the rest_api_explorer role can access the list of available client applications by
navigating to System Web ServicesRESTExample Client Apps.

When viewing the list of applications, click an application to view the source code and
additional documentation hosted on GitHub.

## Developer training {#c_RESTAPI__section_my5_szb_2hb}

On the ServiceNow®
Developer Site, you can get training for [Inbound REST integrations](https://developer.servicenow.com/app.do#!/training/article/app_store_learnv2_rest_rome_inbound_rest_integrations/app_store_learnv2_rest_rome_inbound_integrations_in_servicenow_objectives?v=vancouver) and [Outbound REST integrations](https://developer.servicenow.com/app.do#!/training/article/app_store_learnv2_rest_rome_outbound_rest_integrations/app_store_learnv2_rest_rome_outbound_integrations_in_servicenow_objectives?v=vancouver).

## Additional information {#c_RESTAPI__section_mjd_vbj_zhb}

The remainder of the REST API section contains "how to" topics that describe specific
implementations using the ServiceNow REST
API and provides reference information that describes various data elements used by the ServiceNow REST API.
* **[Use the REST API Explorer](https://www.servicenow.com/docs/VV5d3pcHRv4pFxM~yEJQZA)**   
  In this tutorial you will use the REST API Explorer to test the ServiceNow REST APIs.
* **[Inbound REST API rate limiting](https://www.servicenow.com/docs/t6hg0aS~DLhfIqbnbnwDBw)**   
  To prevent excessive inbound REST API requests, set rules that limit the number of inbound REST API requests processed per hour. You can create rules to limit requests for specific users, users with specific roles, or all users.
* **[Debug in-bound REST queries](https://www.servicenow.com/docs/ckA0QVpQF~efoLNXtjNd5g#debugging-rest-queries)**   
  You can debug in-bound REST queries by reviewing the session debug log.
* **[Return session debug logs in a REST response](https://www.servicenow.com/docs/PnBYy5y51bB807USb1eNnQ)**   
  You can include session debug logs in a REST response body by passing the X-WantSessionDebugMessages header in the request.
* **[CORS domain requirements](https://www.servicenow.com/docs/FjicrdekDPtyCrRVOBytlQ)**   
  When you define a cross-origin resource sharing (CORS) rule, the value you enter in the Domain field must meet certain requirements. Each CORS rule supports a single wildcard to match incoming Origin headers.
* **[Define a CORS rule](https://www.servicenow.com/docs/GUuYHh9hUgILxz1xR4~3TA)**   
  You can define a CORS rule to control which domains can access REST API endpoints and other web resources.
* **[Enable OAuth with inbound REST](https://www.servicenow.com/docs/vwQ2wKaOE3p1_dOfVu2RaQ)**   
  Using OAuth, you can pass a user ID and password once, and then use a token for subsequent REST requests instead of submitting credentials with each request.
* **[REST API HTTP response codes](https://www.servicenow.com/docs/MWP_rWcHNMeh4T87kf2~mA)**   
  REST messages sent to an instance return a specific HTTP response code.
* **[Scripted REST APIs](https://www.servicenow.com/docs/cpRBis~pwSIJPZVsP8Hkxw)**   
  The scripted REST API feature allows application developers to build custom web service APIs.

**Related topics**   

* [REST API FAQ](https://support.servicenow.com/kb_view.do?sysparm_article=KB0535048)

*[\>]: and then