ServiceNow REST API parameters

1. ServiceNow REST API parameters REST is a stateless architecture that establishes standards amongst web-based computer systems, allowing them to communicate more easily. The Now Platform includes number of REST APIs that are enabled by default. These APIs allow you to communicate with different ServiceNow features from within your application. Create, read, update, and delete (CRUD) actions on existing tables (Table API), insert data into, receive information from, and run transforms against a MetricBase database (MetricBase Time Series API), and many more features are available. The format of a REST URI and the parameters REST APIs from ServiceNow follow the standard REST API protocol. They also offer "custom" URI and query parameters for backward compatibility, as well as extra features like pagination for extensive lists of results. The functionality underlying these custom parameters, which are all optional, is described in the sections below. Versioning of REST APIs A version number may be included in ServiceNow REST API URIs, such as /API/now/v1/table/tableName. The endpoint version that a URI visit is identified by its version number. You may assure that future REST API updates have no detrimental influence on your integration by including a version number in your URIs. URIs without a version number, such as /API/now/table/tableName, use the most recent REST endpoint for your instance version. REST API headers Various headers are supported by the ServiceNow REST API. For some endpoints and HTTP methods, certain headers are required. Headers for data formats For requests with a request body or response body, REST APIs require the Accept and Content-Type request headers for proper data formatting. Both headers are required for POST, PUT, PATCH, and DELETE actions. Only the Accept header is required for getting and HEAD operations. A 400 Bad Request error is returned if the required headers are not provided. The following values are supported by most ServiceNow REST API request headers: Accepted file types are application/json and application/xml. application/json, application/xml (Content-Type) Other subheadings An authentication header may be present in all requests, indicating the user credentials to be used for authentication.

2. The X-HTTP-method-override header can also be used to override HTTP methods like getting and POST. Parameters for custom queries Many of the accessible ServiceNow REST APIs use the following query parameters to provide uniform behavior across the APIs. To paginate big data sets, filter results, and limit the number of records returned in a single query, use these arguments. REST API requests with dot-walking When specifying the system query or system fields parameters in queries to REST APIs that accept those parameters, you can employ dot-walking. Dot-walking is not supported by the Import Set API. sysparm query's dot-walking By dot-walking in the sysparm query option, you can filter queries based on related record values. You can, for example, get a list of all incident records when the incident Company has a specified Stock symbol. sysparm fields dot-walking Dot-walking in the sysparm fields option allows you to see field values from many tables. You can, for example, get the Name, Sys id, and Department of each user who has a specific job, as well as the role Name. The User Roles [sys user has role] table, which describes a many-to-many link between users and roles, is used to process the request. Field values from the User [sys user] and Roles [sys user role] databases are included in the response. { "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",

3. "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" } } ] } HTTP response codes for REST APIs

4. HTTP response codes are returned by REST endpoint calls. These response codes can be used to verify that the REST API worked properly. If it didn't, the endpoint responds with an error code. To troubleshoot issues with your call format, use the information in the error response. See REST API HTTP response codes for a list of standard response codes that an endpoint may return. See the REST API reference for a list of response codes returned by each ServiceNow REST API. Security of REST APIs Basic authentication or OAuth are used by default in ServiceNow REST APIs to permit user access to REST APIs/endpoints. To access REST APIs, you can also enable your instance to use multi-factor authentication. Inbound mutual authentication is not supported. In the same manner that an interactive user is subject to access control, the user ID you supply in a REST endpoint call is. Each request necessitates the input of appropriate authentication data, such as a user name and password. Make that each API request has an Authorization header with enough credentials to access the endpoint. Roles in the REST API Each REST endpoint can have distinct criteria for the roles required to access the endpoint in addition to user authentication. Some call for the admin job, while others call for API-specific roles. The access control list (ACL) linked with the REST API/endpoint specifies the role criteria. Refer to the REST API reference for specifics on the valid roles for each REST API/endpoint, or look up the associated ACL for the API/endpoint within an instance under Security System > Access Control (ACL). ACLs for REST APIs REST API ACLs set requirements for accessing a ServiceNow REST API or endpoint, such as required roles and conditions. A single ACL can be established for an entire REST API, such as the Table API and Attachment API ACLs, or for a single endpoint, such as the clotho rest put ACL for MetricBase PUT methods only. The ServiceNow REST API ACLs listed below are available in the base system, although they are disabled by default. By default, all other ServiceNow REST API ACLs are active. Access to tables through the REST API Web services are available by default for all tables, including base system tables, global tables, and scoped tables. To access tables through web services, you must meet any web service security requirements, such as basic authentication and ACLs. Add the table name to the Public Pages [sys public] table with an Active state to allow access to tables without any login or authorisation. Any defined ACLs on connected tables are still enforced by the REST interface. If you don't want ACL enforcement, you'll have to deactivate the ACLs on the tables, which isn't recommended. The Allow access to this table via web services check box on the table application access settings can also be used to control direct web service access to tables. This check box must be selected to allow web service interaction with the table.

5. Note that application access parameters such as Can read and Can create, which control CRUD operations, do not apply to web service requests. RESTful inbound authentication with several factors When a user account has multi-factor authentication enabled, you must submit an MFA token along with basic authentication credentials when making REST calls as that user. Append the token to the end of the user's password in the basic auth username: password string, such as joe. employee:password62161147, to send an MFA token with a REST request. Use base64 encoding to encode the entire string, including the MFA token, and then send the encoded string in the Authorization header. Conclusion You may utilize the Automated Test Framework to test your Scripted REST APIs, which is an underappreciated capability. I believe in having as much automation coverage as possible, therefore using tests to backstop API development is a smart idea. You can learn more about REST API through ServiceNow online training.