--- sourceDocument: Brazil API Reference sourceDocumentLink: https://www.servicenow.com/docs/r/api-reference Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil API Reference ft:clusterId : - crapiref bundleId : - crapiref workflow : - Creator --- # Scripted REST APIs good practices # Scripted REST APIs good practices {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Scripted REST APIs good practices This guidance helps ServiceNow customers design and implement scripted REST APIs following best practices to ensure consistency, reliability, and security. Adhering to REST API conventions and employing proper versioning, error handling, access control, and testing will provide a robust API experience for clients and protect integrations from breaking changes. Show full answer Show less ## Follow REST API conventions * **GET**: Only query data; do not modify. * **POST**: Create new records without modifying existing ones. * **PUT/PATCH**: Modify existing records. * **DELETE**: Remove records. Using these standard HTTP methods ensures a predictable and easy-to-use interface for clients. ## Use versioning to control API changes Introduce new API functionality in new versions instead of altering existing published versions. This avoids breaking existing integrations and allows clients to upgrade on their own schedule. Encourage clients to specify version explicitly, either by requiring version-specific endpoints or omitting a default version. Optional new behaviors can be added via parameters within existing versions. ## Return informative HTTP status codes * **200**: Request completed successfully. * **201**: Record created successfully. * **204**: Record deleted successfully. * **40X**: Client errors, e.g., 400 (bad request), 404 (not found). * **50X**: Server errors, indicating processing failures. Appropriate status codes help clients understand request outcomes immediately. ## Return useful error information Include clear, descriptive error messages alongside relevant status codes to minimize client confusion and reduce dependence on external documentation. For example, use messages like "The specified record does not exist" with a 404 status code. Utilize preconfigured error objects provided by the scripted REST API feature or customize error responses as needed. ## Enforce and test access controls Apply authentication and authorization rigorously. Use the `GlideRecordSecure` API to enforce underlying data access controls for requesting users. Require stricter access for data-modifying operations (PUT, POST, DELETE) compared to read-only GET requests. Thoroughly test both authentication and authorization before releasing the API. ## Build tests to verify functionality Develop repeatable automated tests to validate the API's expected behavior, including response codes, headers, body content, authentication, and error handling. Testing ensures stability across releases and helps identify issues early. Tools like Postman can facilitate automated testing of scripted REST APIs. Follow these guidelines when designing and implementing scripted REST APIs. ## Follow REST API conventions {#scripted-rest-good-practices__section_xwf_flr_23b} Use REST API standards to provide a consistent and easy to use interface for clients. REST API conventions define specific behavior for each type of method. Use the following guidelines as a starting point for designing your API. * GET operations only query data. A GET request should never modify data. * POST operations create new records but do not modify existing records. * PUT and PATCH operations modify existing records. * DELETE operations destroy records. {#scripted-rest-good-practices__ul_tbd_3lr_23b} ## Use versioning to control changes to your API {#scripted-rest-good-practices__section_km4_mlr_23b} Use versioning to implement new functionality and avoid breaking existing integrations. When you introduce significant functionality changes to your API, create a new version of the API first. Do not introduce behavior that will break existing integrations in a published version. Using versioning allows you to implement significant changes to your API without breaking existing clients. You can then release the new version of the API for new clients while allowing existing clients to upgrade at their own pace. Encourage clients to use a version-specific API, or configure the API without a default version to force clients to specify a version. You can also make new, optional behavior available by adding an optional parameter to an existing version. ## Return an informative HTTP status code {#scripted-rest-good-practices__section_xbn_qlr_23b} Return a status code that informs the requestor of the success or failure of the request. Return an HTTP status code that helps the client understand the result of the request. Use the following guidelines for common status codes. {#scripted-rest-good-practices__table_cbv_2rh_dw__entry__2} | Status code | Description | |-|-| | 200 | Indicates that the request was completed successfully. | | 201 | Indicates that a record was created successfully. | | 204 | Indicates that a record was deleted successfully. | | 40X (401, 404) | Status codes in the 400 range indicate a client error, such as 400 for invalid request syntax. | | 50X (500, 503) | Status codes in the 500 range indicate that a server error occurred. The client request may have been valid or invalid, but a problem occurred on the server that prevented it from processing the request. | [Table 1. Common status codes] {#scripted-rest-good-practices__table_cbv_2rh_dw} ## Return useful error information {#scripted-rest-good-practices__section_gwd_vlr_23b} Provide the client with enough information in error messages to allow them to understand the problem without having to refer to your API documentation. An error response should include a helpful error message, as well as an error status code. For example, when a client queries a record that does not exist, you can return the error message "The specified record does not exist. Ensure that a record with the ID of \ exists in the application." along with a 404 status code. The scripted REST API feature includes several preconfigured error objects you can use for commonly-encountered errors, and a customizable ServiceRequest error object you can use when the preconfigured error objects do not meet your needs. ## Enforce and test access controls {#scripted-rest-good-practices__section_efh_1mr_23b} Enforce existing access controls and require additional access to modify data. In addition to requiring authentication to access the API, require authorization to access data. Use the GlideRecordSecure API in your scripted REST API scripts. This API ensures that access controls defined on the underlying data are applied for the requesting user. Require additional access controls for operations that modify data. Requests such as PUT, POST, and DELETE should require a higher level of access than GET. Configure these API resources to require a more strict ACL. Test your access controls, both authentication and authorization, before releasing the API. ## Build tests to verify functionality {#scripted-rest-good-practices__section_hlf_hmr_23b} Build tests that verify your scripted REST web services functionality as part of your development process. Use repeatable tests to ensure that your API functions the way you expect it to. Testing also helps ensure that changes you make do not affect the expected API behavior after you release a version. You can use a REST client application that supports automated testing, such as Postman, to facilitate testing. Tests should validate the response code, headers, and body content as appropriate for each resource you implement. You can also use tests to validate authentication requirements, and to confirm that errors return useful responses.