ServiceNow accepts HTTP basic authentication (use the Basic Credentials tab) or inbound REST API keys (Washington DC or later). A REST API key is bound to a ServiceNow user; roles and ACLs on that user govern Table API access the same way as with basic authentication. Synqly stores the REST API key value in the Token field in integration settings. Open the Generating Credentials tab you need.
For creating the inbound profile, REST API key, and REST API Access Policy in ServiceNow, see Inbound REST API Keys.
This guide covers ServiceNow Security Incident Response (SIR)—sn_si_incident and related SIR data—in addition to standard ITSM Incident access. Assign the same ITSM roles as the standard ticketing guide, plus sn_si.manager for SIR. Each tab explains ServiceNow roles for that authentication path. For Incident-only integrations (no SIR), see the ServiceNow Ticketing Provider Configuration Guide.
ServiceNow supports two authentication methods for this integration, shown as tabs below.
Token (recommended) — For instances on Washington DC or later. You configure REST API key authentication in ServiceNow (enable the plugin, create an inbound authentication profile, REST API key, and access policy), then paste the key into the integration Token field.
Basic Credentials — A dedicated service account with username and password. Setup is shorter: create the user, assign the ITSM and SIR roles listed in that tab, and set a password. You do not create REST API key records or access policies.
The same ITSM and SIR roles apply in both tabs; only how the integration authenticates differs. If your administrators or security policy require REST API keys, use the Token tab—basic credentials are not a substitute.
Table API requests are authenticated with a dedicated ServiceNow user that is tied to the REST API key. Collections on that user define query, create, read, and update behavior on the Incident table and Security Incident Response (sn_si_incident) records. Complete steps 1–3 first, then assign collections on the integration user in step 4 using the role-assignment tables in step 3.
Once logged in, first verify that the API Key and HMAC Authentication plugin is enabled. Navigate to All > Admin Center > Application Manager and verify the plugin API Key and HMAC Authentication (com.glide.tokenbased_auth) is activated. If it is not enabled, activate it.
Once logged in, click on the face icon, and click on Elevate Role. Click on security_admin. This will allow you to create the necessary roles and permissions.
Navigate to All > System Security > Users and Groups > Roles. Click New and create a new custom role. Note the role name.
Recommended minimal collections for standard Incident and Security Incident Response (SIR) CRUD and query (assign on the integration user in step 4):
| Collection | Purpose |
|---|---|
itil | Baseline ITSM incident operations via Table API. |
itil_admin | Additional incident capabilities commonly required for integrations. |
snc_internal | Collections ServiceNow expects on integration-style users for routine platform reads. |
personalize_decision_table_input | Table API reads on sys_choice for incident status labels; omitting it often surfaces HTTP 403 on those reads. |
sn_si.manager | Security Incident Response on sn_si_incident and related SIR data via Table API. |
Also assign the custom role from step 3 whenever you use step 8's optional Incident ACL pattern or your administrators keep that role on the user.
Optional collections—add only when the capability is in scope:
| Collection | Use when |
|---|---|
u_ticket_user | Custom extended ticketing (for example records on u_ticket), not only Incident. |
admin | Webhooks or automation touch sys_script; prefer a narrower role your admins define when possible. |
sn_incident_write | Standard Incident table only—narrow create/edit via the ITSM Roles plugin (com.snc.itsm.roles) when admins prefer granular roles instead of itil; does not apply to SIR (sn_si_incident). Usually redundant if itil is already assigned. |
Standard Incident only: sn_incident_write and itil are separate ServiceNow roles. itil bundles broader ITSM responsibilities; sn_incident_write is a scoped write role from the ITSM Roles plugin and is not inherited by itil. If itil is already assigned, adding sn_incident_write is usually redundant for standard Incident access.
SIR is separate: Security Incident Response on sn_si_incident relies on sn_si.manager (in the minimal bundle above), not sn_incident_write or the itil/sn_incident_write trade-off.
Assign the recommended minimal collections above (itil, itil_admin, snc_internal, personalize_decision_table_input, and sn_si.manager), plus the custom role from step 3 when you use step 8 or admins require it. Add optional collections only when a row in the optional table applies to your scope.
If authentication succeeds but security incident data looks incomplete or incorrect—for example, standard incidents sync but SIR records do not, fields stay read-only or empty, or status values show as raw codes instead of labels—the integration user's ServiceNow roles or ACLs are the usual cause, not the REST API key. Confirm the roles in the tables above, especially personalize_decision_table_input (needed for status labels from sys_choice) and sn_si.manager, and any custom ACLs your administrators added.
This step is optional, but recommended rather than using an account of an employee. If the employee leaves and their account is deactivated, your API could stop working.
Navigate to All > Organization > Users. Select New from the upper right corner. Fill in the required fields, making sure to select the Internal Integration User field.
Once the user is created, select it from the list of all users. In the Roles tab, select Edit... and assign the custom role from step 3 plus the collections from the role-assignment tables above—typically itil, itil_admin, snc_internal, personalize_decision_table_input, and sn_si.manager, plus any optional collections when they apply.
Navigate to All > System Web Services > API Access Policies > Inbound Authentication Profile. Click New and then click Create API Key authentication profiles.
Provide a name for the profile that reflects its use as a REST API key for an integration.
In the Auth Parameter field, add Auth Header using the x-sn-apikey header field. This header carries the REST API key on each request.
Click Submit.
Navigate to All > System Web Services > API Access Policies > REST API Key. Click New and fill in a name for the key. Select the user created in step 4 as the User. Whatever this user may do in ServiceNow—per the role-assignment tables in step 3—applies to traffic authenticated with that REST API key.
Create the key by clicking Save.
The system generates the REST API key value. Click the lock icon to view it, copy the value shown below the field, and store it securely. You will paste this value into the integration Token field when you complete Configure the integration below.
Navigate to All > System Web Services > API Access Policies > REST API Access Policies. Click New.
Provide a descriptive name. Under REST API, select Table API. Leave Apply to all methods checked unless your security team requires a narrower policy (ServiceNow allows limiting methods or resources on the form).
On the policy form, add the Inbound Authentication Profile from step 5 to the embedded list for authentication profiles, then click Submit. Skipping this step is a common reason REST API key requests fail even when the key and user are correct.
Some organizations pair the custom role from step 3 with an explicit ACL on the Incident table. This pattern is not a substitute for the ITSM and SIR role bundle in the role-assignment tables in step 3 (itil, itil_admin, snc_internal, personalize_decision_table_input, and sn_si.manager): read, query, and patch are still governed by ServiceNow ACLs and roles on your instance. This step covers the Incident table only; Security Incident Response tables such as sn_si_incident rely on sn_si.manager and any separate ACLs your administrators define. Use step 8 only when your administrator requires this extra ACL for create (or additional operations they define).
Navigate to All > System Security > Access Control (ACL) > New.
In the Type field, select record.
In the Operation field, select Create.
In the Name field, select Incident.
In the Roles field under Requires Role, select the role created in step 3.
Finalize the ACL by clicking Submit.
If you use basic authentication for other integrations that use the Table API, add a basic auth authentication profile to this policy as well, or use a separate policy for those integrations. ServiceNow applies authentication in priority order; adding only a REST API key authentication profile can change default basic auth behavior for Table API traffic covered by this policy.
In your integration or connector settings, supply:
URL
The root URL of your ServiceNow instance, for example https://<tenant>.service-now.com/.
Token
Paste the REST API key value from 6. Create an API Key into the integration Token field.
If the integration still fails after entering these values, see Troubleshooting.
If authentication or data access still fails after you save the integration, work through these checks with whoever administers your ServiceNow instance.
- Connection errors, "access denied," or an apparently invalid Token value: Paste the REST API key into the Token field again from Create an API Key, with no leading or trailing spaces. If the key was regenerated in ServiceNow, update the integration to match. In ServiceNow, revisit step 5 (Inbound Authentication Profile): if your team changed the header setup, align it with this guide—when you follow the steps as written, Auth Header uses
x-sn-apikey. - Same failure after re-checking Token and URL: Open the REST API Access Policy you created and confirm the Inbound Authentication Profile appears on that policy's embedded list for authentication profiles, not only saved elsewhere. Without that link, ServiceNow may not attach your REST API key to Table API traffic (Set the API Access Policy).
- Some incidents or security incidents missing or not updatable: Usually role design, not the Token value or REST API key wiring. In the Token (recommended) tab, confirm the integration user has
itil,itil_admin,snc_internal,personalize_decision_table_input, andsn_si.manager—see the role-assignment tables in step 3.
If it still fails, your ServiceNow administrator can use Script/REST or transaction logs on their side to see why a call was rejected.
To configure custom fields for this integration, see the ServiceNow Ticketing Provider Custom Fields Configuration Guide.