Integrations call ServiceNow over REST, either through the generic Table API or a Scripted REST API you design. The choice affects stability, security and how much internal structure you expose.
Before you start
You should be comfortable with tables and server scripts. This article covers REST options and versioning.
Step-by-step walkthrough
Step 1: Choose Table API or Scripted REST
The Table API exposes tables directly with CRUD over HTTP, which is quick but ties callers to the schema and ACLs. A Scripted REST API defines custom endpoints and payloads, which decouples callers from internal tables and lets you shape the contract.
Step 2: Version and shape the contract
Put a version in the Scripted REST API’s namespace or path, such as /api/v1/, and return a stable payload you control. A custom resource can map internal fields to a public shape, so renaming an internal field does not break integrations.
Step 3: Validate, authorize and limit
Validate input, enforce authorization on the endpoint, and bound the response size and query to avoid expensive reads. A public endpoint must not trust the caller, so server-side validation and ACLs apply as much as in the UI.
Worked scenario
The Scripted REST response maps internal fields to a public shape.
{
"id": "INC0010001",
"summary": "Printer offline",
"state": "in_progress"
}Walk through the example
The endpoint returns summary and state rather than the table’s internal field names, so the integration depends on the contract, not the schema. A version in the path lets you add /v2/ when a breaking change is needed, running both until callers migrate. Internal table changes stay hidden.
Common mistake
Exposing the raw Table API to external callers, so a schema change or ACL update breaks the integration, or returning internal field names that leak structure. Another is no versioning, so any change is breaking.
Verify the behavior
Call the endpoint and confirm the payload matches the documented contract. Rename an internal field and confirm the API still returns the public shape. Enforce authorization and confirm an unauthorized caller is rejected.
Interview exercise
When is the Table API acceptable instead of a Scripted REST API?
Answer and reasoning
For internal or short-lived integrations where the caller is trusted and can tolerate schema changes, and where the ACLs already enforce access. A Scripted REST API is better when the contract must be stable, the audience is external, or you need to shape and validate the payload. The Table API is faster to set up, the Scripted API is more durable.
Continue learning
Compare integration contracts in GlideAjax contracts and failures in Integration failures. Read the ServiceNow REST API documentation and try the ServiceNow interview questions.