ServiceNow Response Integration via API

Updated August 03, 2026 09:17

Purpose

This guide explains how to connect Logsign's Responses module to ServiceNow so that an incident or alarm in Logsign can automatically or manually create an incident record in ServiceNow, without an analyst having to switch tools. This is a Response/Action integration, not a log collection poller: Logsign does not pull any data from ServiceNow on a schedule. It only calls the ServiceNow REST API when a Logsign action rule fires, or when an analyst runs the action manually from the Incident module.

The integration also exposes three lookup methods (category, user, and assignment group lists) that Logsign uses to populate the pick-lists shown when you configure the "Create Incident" action, so the values you select match what actually exists in your ServiceNow instance.

Prerequisites

You need a ServiceNow instance reachable from the Logsign server over HTTPS (port 443), a ServiceNow user account dedicated to this integration, and an OAuth Application Registry entry on the ServiceNow side (Client ID and Client Secret). The exact minimum Logsign version this integration first shipped in is not independently verified; check with your Logsign contact if you are on an older release and do not see ServiceNow under Settings > Integrations > Responses.

Authentication uses OAuth 2.0 with the Resource Owner Password Credentials grant: Logsign exchanges your integration user's username and password, together with the Client ID and Client Secret from the Application Registry entry, for a bearer token on every call. There is no separate OAuth consent screen and no redirect URL to configure.

Step 1: Create a ServiceNow API user

Do not point this integration at a named employee's account or at an administrator. Create a dedicated service account instead, and give it only the access the integration actually needs.

In ServiceNow, go to System Security > Users and Groups > Users and create a new user for the integration (for example svc-logsign-response). Set a password for it, since the password grant requires one, and if your instance supports it, set the user field Web service access only to true. This blocks the account from logging into the ServiceNow UI interactively while still allowing it to authenticate for API calls, which reduces the blast radius if the credentials ever leak.

For the role, avoid admin. Based on how the integration is implemented, the account needs: create access on the incident table, and read access on sys_user, sys_user_group, and sys_choice (these three back the category, user, and assignment group lookups). The standard ServiceNow itil role covers all four of these out of the box and is the role most ServiceNow admins already use for agent/API accounts, so it is a reasonable default. You will also see a web_service_admin role on most instances; it is broader than it sounds and effectively grants API access comparable to admin across any table exposed to web services, so it is not a least-privilege choice for this integration. If your security policy requires tighter scoping than itil, build a custom role instead and attach it to explicit ACLs for incident.create, sys_user.read, sys_user_group.read, and sys_choice.read. This role guidance follows ServiceNow's own documented ACL model; it has not been independently re-verified against a live Logsign customer tenant, so confirm the exact permissions with a test run before rolling it out broadly.

Next, register the OAuth client. Go to System OAuth > Application Registry > New, choose Create an OAuth API endpoint for external clients, give it a name such as "Logsign Responses", and save it. ServiceNow generates a Client ID and Client Secret for the entry; copy both immediately; the secret is not always shown again in plain text later, depending on your instance's policy. No redirect URL is needed for the password grant flow.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for "ServiceNow", click Configure, then +Device. Fill in the fields below and click Create.

Field	Description	Example	Required
Device Name	A label to identify this configuration inside Logsign.	ServiceNow-Prod	Yes
Host	The base URL of your ServiceNow instance. Enter it without a trailing slash; the integration appends API paths such as `/api/now/table/incident` directly to this value.	Correct: `https://dev12345.service-now.com`. Avoid a trailing slash such as `https://dev12345.service-now.com/`.	Yes
Username	The username of the dedicated ServiceNow integration user created in Step 1.	svc-logsign-response	Yes
Password	That user's ServiceNow password. Stored encrypted and masked in the UI.	(hidden)	Yes
Client Id	The Client ID from the OAuth Application Registry entry created in Step 1.	a1b2c3d4e5f6...	Yes
Client Secret	The Client Secret from the same Application Registry entry. Stored encrypted and masked in the UI.	(hidden)	Yes
Insecure Skip Verify	Whether to skip TLS certificate validation on calls to ServiceNow. It defaults to true (verification skipped). For a production instance with a publicly trusted certificate, set this to false; only leave it true if you are deliberately connecting to a self-signed or internal test instance.	false (recommended for production)	Yes

Click Test before saving. Be aware that the test only confirms the username, password, Client ID and Client Secret are valid enough to obtain an OAuth token; it does not call the incident or lookup tables, so it will not catch a missing role or ACL. A method can still fail with 403 even after a successful test.

Available Methods

These are the actions the ServiceNow device exposes to Logsign's Responses module, either as steps in an automated action rule or as manual actions from the Incident module.

get_category

Returns the list of category values defined on the incident table's Category choice list in ServiceNow, as label/value pairs. Logsign uses this to populate the Category picker when you build a Create Incident action, so the value you pick already exists in your instance. It takes no arguments.

Argument	Type	Description
None

get_user_list

Returns the list of user names from the ServiceNow sys_user table, used to populate the caller/user picker shown when configuring Create Incident. It takes no arguments. The call is not filtered, so on a large instance it returns every user record's name in one response; see Notes and Limits below.

Argument	Type	Description
None

get_assignment_group

Returns the list of group names from the ServiceNow sys_user_group table, used to populate the Assignment Group picker. It takes no arguments and is not filtered, so it returns every group defined on the instance.

Argument	Type	Description
None

create_incident

Creates a new record on the ServiceNow incident table. This is the action you typically attach to a Logsign action rule, so that a correlation or alarm opens a matching ServiceNow incident automatically.

Argument	Type	Description	Required
Short Description	String	The incident's short description (title) field.	Yes
Description	String	The incident's full description field.	Yes
Urgency	Enum: High, Medium, Low	Mapped to ServiceNow's numeric urgency scale: High = 1, Medium = 2, Low = 3.	Yes
Impact	Enum: High, Medium, Low	Mapped to ServiceNow's numeric impact scale the same way: High = 1, Medium = 2, Low = 3.	Yes
Category	String	Should exactly match one of the values returned by get_category.	Yes
User List	String	Despite the name, this sets a single value: the incident's Caller. Should exactly match one of the values returned by get_user_list.	Yes
Assignment Group	String	Should exactly match one of the values returned by get_assignment_group.	Yes

On success, ServiceNow returns the full created incident record, including its number (for example INC0012345) and sys_id. Category, Caller, and Assignment Group are reference fields in ServiceNow, and Logsign sends them as plain text names rather than internal sys_id values. If a name does not exactly match an existing record, or matches more than one, ServiceNow may create the incident with that particular field left empty instead of returning an error. This behavior follows from how the integration builds the request; it has not been independently confirmed against a live tenant, so on your first test run, open the created incident in ServiceNow and confirm Caller and Assignment Group were actually populated before relying on this in production.

Notes and Limits

This integration only creates new incidents. It does not update an existing incident, add a comment or work note, change state, or attach a file. If your process needs any of those, they are not currently available through this device and would need to be handled in ServiceNow directly or requested as a product enhancement.
Every single call, including the Test button and each of the three lookup methods, performs a fresh OAuth password-grant token request before doing anything else; the token is not cached or reused between calls. In practice this means each action against ServiceNow involves two HTTP round trips (get a token, then call the API), and your ServiceNow login/audit log will show a new authentication event from the integration user for every action, not just once per session.
get_user_list and get_assignment_group query sys_user and sys_user_group with no filter and no page size limit. On a large ServiceNow instance this can be a slow call and returns the name of every user or group in one response, which is worth knowing if your ServiceNow admin asks why the integration account is reading the entire user table.
Insecure Skip Verify defaults to true, meaning TLS certificate validation is skipped by default. Set it to false for any production instance with a valid certificate; only leave it true against a self-signed or internal test instance.
When a call fails, Logsign currently surfaces only the raw HTTP status (for example "403 Forbidden"), not ServiceNow's own JSON error detail. There is no automatic retry on failure, including on rate-limit (429) responses. If an action fails with no obvious cause, re-run the same request with curl against the same ServiceNow instance and credentials to see the full error body.

Troubleshooting

Symptom	Likely cause	What to check
Test fails, or every method fails with an authentication error	Wrong Username/Password, or the Client Id/Client Secret does not match an active Application Registry entry, or the integration user account is locked or inactive.	Confirm the integration user's password is current and the account is active. Confirm the Application Registry entry in ServiceNow is still Active and that Client Id/Client Secret were copied without extra spaces or line breaks.
HTTP 401 Unauthorized on a specific method	Since a fresh token is requested before every call, a 401 here usually means the token that was just issued was itself rejected, most often because the user's password was changed or reset after the Logsign device was configured.	Re-enter the current password in the Logsign device configuration and re-test. Confirm the Application Registry entry has not been deactivated on the ServiceNow side.
HTTP 403 Forbidden	Credentials are valid (Test passed) but the integration user's role does not have ACL access to the table being called: incident, sys_user, sys_user_group, or sys_choice.	Add the itil role, or the equivalent custom ACLs, to the integration user for whichever table the failing method touches. See Step 1 for the specific tables each method needs.
HTTP 404 Not Found	The Host field does not point at the correct ServiceNow instance, or a proxy/load balancer in front of the instance is rewriting the request path before it reaches `/api/now/table/...`.	Confirm Host exactly matches your instance URL with no trailing slash. If there is a proxy between Logsign and ServiceNow, confirm it passes the request path through unchanged.
HTTP 429 Too Many Requests	The ServiceNow instance's inbound REST rate limit was reached. This is more likely here than on a typical integration, since every action (including the three lookup methods) performs an extra token request on top of the actual API call.	Space out how often the action or lookup is triggered. Ask your ServiceNow administrator whether a rate limit policy is applied to this user and whether it can be raised. Logsign does not automatically retry a 429; the action needs to be re-triggered manually.
Incident is created, but Assignment Group or Caller is blank on the ServiceNow record	The Category, User List, or Assignment Group value typed into the action did not exactly match an existing ServiceNow record name.	Re-run get_category, get_user_list, or get_assignment_group to get the current exact values and use those, rather than typing a value from memory.
get_category returns an empty list	The lookup filters specifically on the incident table's category choice list by internal name. If that choice list was renamed, or your instance uses domain separation, no rows come back.	In ServiceNow, check System Definition > Choice Lists that the incident table's Category field still uses the element name "category", and check whether domain separation is enabled on the instance.

ServiceNow's own REST API documentation does not publish a complete list of error codes for the Table API beyond the general HTTP status meanings above (401 unauthorized, 403 no ACL access, 404 record or table not found, 429 rate limited). The rows above combine that general guidance with what the integration code itself actually does with a failed response, which is to surface the raw status text with no further parsing or retry.