AI Agent API for ServiceNow: Integration Guide

What "AI agent API ServiceNow" actually means

If you're searching this, you're probably trying to do one of two things: build an AI agent that can read and write ServiceNow records (incidents, requests, CMDB items) through its REST API, or find out whether ServiceNow itself ships a native agent framework you can call as a service. The short answer is that ServiceNow has its own AI capabilities (Now Assist, Virtual Agent) but for custom agent workflows — the kind where an LLM decides which ServiceNow endpoint to call, extracts data, and takes action — you're building this yourself by combining ServiceNow's REST API with an LLM that supports tool/function calling.

This article covers the actual architecture: how the pieces fit together, what the ServiceNow side looks like, and how to wire an LLM to it as the reasoning layer.

The two APIs involved

An agent that works with ServiceNow needs two distinct API integrations, and confusing them is the most common source of wasted time:

1. ServiceNow's Table API / REST API — this is what lets your agent read and write incident, sc_request, change_request, cmdb_ci, and other tables. It's authenticated with OAuth2 or basic auth against your instance (https://yourinstance.service-now.com/api/now/table/incident).
2. The LLM API — this is the model that reasons about a user's request ("close all stale incidents assigned to me older than 30 days"), decides which ServiceNow calls to make, and formats the response. This is a completely separate API, typically Claude, GPT, or similar.

ServiceNow doesn't give you an "AI agent API" out of the box that does the reasoning for you on custom logic — you supply that layer.

Basic architecture

User request
   │
   ▼
LLM (tool calling) ──► decides which ServiceNow endpoint to call
   │
   ▼
Your backend executes the ServiceNow REST call
   │
   ▼
Result returned to LLM ──► LLM formats final answer

This is the standard tool-use loop: the model doesn't call ServiceNow directly, your code does, based on the tool call the model requests.

Defining ServiceNow as a tool for the LLM

Most modern LLM APIs support structured tool definitions. Here's how you'd describe a "query incidents" tool to a model with function/tool calling:

{
  "name": "query_servicenow_incidents",
  "description": "Query ServiceNow incidents by state, assignee, or priority",
  "input_schema": {
    "type": "object",
    "properties": {
      "state": { "type": "string" },
      "assigned_to": { "type": "string" },
      "priority": { "type": "string" }
    }
  }
}

When the model decides it needs incident data, it returns a tool call with these arguments instead of guessing an answer. Your backend then makes the actual HTTP request to ServiceNow's Table API:

curl -u "$SN_USER:$SN_PASS" \
  "https://yourinstance.service-now.com/api/now/table/incident?sysparm_query=active=true^priority=1"

You feed the JSON result back to the model as the tool result, and it composes a natural-language or structured response. This loop — model calls tool, your code executes it, result goes back — is the core of every ServiceNow agent worth building.

Where the LLM part gets expensive to run reliably

Once you're past the prototype stage, three things become real operational problems:

• Streaming responses so agents feel responsive in a chat UI, rather than waiting for a full completion.
• Per-application API keys so you can separate a ServiceNow incident-triage agent from a change-management agent from an internal chatbot, each with its own usage tracking.
• Tool-use reliability — making sure the tool-calling protocol is stable across requests, with proper streaming of tool call chunks.

This is exactly the layer SubToAPI is built for. Instead of managing raw provider credentials, you generate scoped sub_live_... keys per application, call a stable HTTPS endpoint, and get streaming plus tool use out of the box. For a ServiceNow agent, that means your incident-triage bot, your request-fulfillment bot, and your CMDB-lookup bot can each have their own key, their own usage numbers, and their own rate limits — without you running separate provider accounts for each.

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-20250514",
    max_tokens: 1024,
    tools: [servicenowIncidentTool],
    messages: [
      { role: "user", content: "List all P1 incidents assigned to the network team" }
    ]
  })
});

The tool schema and response format follow the same messages/tools pattern documented at /docs/messages and /docs/tools, so if you've built a tool-calling agent before, wiring in ServiceNow as another tool is a config change, not a rewrite.

Handling ServiceNow-specific quirks

A few things trip up first-time integrations:

• Encoded queries — ServiceNow's sysparm_query syntax (^ for AND, ^OR for OR) is not something the LLM should generate freely. Build a small translation layer between the model's structured arguments and the query string, rather than asking the model to write raw ServiceNow query syntax.
• Pagination — Table API responses are paginated by default (sysparm_limit). Long-running agent conversations should chunk results rather than dumping thousands of rows into the model's context.
• Write actions need confirmation — for anything that creates or closes a record, add an explicit confirmation step before the tool executes, especially if the agent is customer-facing.
• Rate limits on both sides — ServiceNow instances throttle API calls per user token, and your LLM provider has its own limits. Track both independently so a spike in one doesn't silently fail the other.

Getting started

If you already have a ServiceNow instance with API access enabled, the fastest path is:

1. Set up OAuth2 credentials in ServiceNow for your integration user.
2. Define your tool schemas (incident query, incident update, request creation) matching your instance's actual table fields.
3. Get an LLM API key that supports tool calling and streaming — sign up at /signup for a free trial, or check /pricing for the Solo, Team, and Scale plans.
4. Follow /docs/quickstart to send your first request, then move to /docs/streaming once you're building a live chat interface for the agent.

questions

Does ServiceNow provide its own AI agent API? ServiceNow offers Now Assist and Virtual Agent for built-in AI features, but for custom agents that reason over your specific tables and workflows, you connect an external LLM API with tool calling to ServiceNow's REST/Table API yourself.

What authentication does the ServiceNow Table API use? OAuth2 is the recommended method for production integrations; basic auth works for development but is less secure and often disabled on hardened instances.

Can I use the same agent for multiple ServiceNow modules? Yes — define separate tool schemas for incidents, requests, and changes, and give the model access to all of them in one tool-calling session, or split them into separate agents with separate API keys for cleaner usage tracking.