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](https://www.servicenow.com/community/developer-advocate-blog/inbound-rest-api-keys/ba-p/2854924). 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](/guides/provider-configuration/servicenow-ticketing-setup). ## Generating Credentials 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. Token (recommended) 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. ### 1. Log in to ServiceNow as an Admin 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. ### 2. Elevate Role 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. ### 3. Create a Custom Role 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. ### 4. Create a Service Account User 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. ### 5. Create the Inbound Authentication Profile 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**. ### 6. Create an API Key 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](#ticketing-sn-sir-token-roles)—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](#ticketing-sn-sir-token-configure) below. ### 7. Set the API Access Policy 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. ### 8. Create an ACL for table access (optional pattern) 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](#ticketing-sn-sir-token-roles) (`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. ### Configure the integration In your integration or connector settings, supply: **URL** The root URL of your ServiceNow instance, for example `https://.service-now.com/`. **Token** Paste the REST API key value from [6. Create an API Key](#ticketing-sn-sir-token-step-6-create-api-key) into the integration **Token** field. If the integration still fails after entering these values, see [Troubleshooting](#troubleshooting-sir-token). ### 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](#ticketing-sn-sir-token-step-6-create-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](#ticketing-sn-sir-token-step-7-api-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`, and `sn_si.manager`—see the [role-assignment tables in step 3](#ticketing-sn-sir-token-roles). If it still fails, your ServiceNow administrator can use Script/REST or transaction logs on their side to see why a call was rejected. Basic Credentials HTTP basic authentication uses a dedicated ServiceNow user (username and password). Collections on that user define Incident table and Security Incident Response (`sn_si_incident`) access. Review the role tables in step 1, then create the integration user and assign those roles in step 2. You typically do not need an extra custom integration role unless administrators tied an optional Incident ACL to one—in that case they create the role and ACL first, then you assign that role along with the collections in step 1. For HTTP paths, see [Ticketing accessed provider endpoints](/guides/connectors/ticketing/accessed-provider-endpoints). ### 1. Role assignments for the integration user Recommended minimal collections for standard Incident and Security Incident Response (SIR) CRUD and query (apply when you assign roles on the integration user in the next step): | 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. | Add any custom role your administrators defined for an optional Incident ACL, if they use that pattern. 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 any custom ACL role admins defined. 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 username or password. 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. ### 2. Create a Service Account User Navigate to **All > Organization > Users**. Select **New**. Fill in the required fields, including **Internal Integration User**. Once the user exists, open it, select **Edit...** on **Roles**, and assign collections from the role-assignment tables above. Create a password for the user. Store the username and password securely. You do not create an Inbound Authentication Profile, REST API Key record, or REST API Access Policy for Table API when using this procedure. ### 3. Configure the integration In your integration or connector settings, supply: **URL** The root URL of your ServiceNow instance, for example `https://.service-now.com/`. **Username** The service account from [2. Create a Service Account User](#ticketing-sn-sir-basic-step-2-service-account). **Password** Use with **Username** for HTTP basic authentication—that account's password. ## Custom Fields To configure custom fields for this integration, see the [ServiceNow Ticketing Provider Custom Fields Configuration Guide](/guides/provider-configuration/servicenow-custom-fields-setup).