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).

Each tab explains ServiceNow roles for that authentication path. For Security Incident Response (SIR) on `sn_si_incident`, see the [ServiceNow Ticketing (Security Incident Response) Configuration Guide](/guides/provider-configuration/servicenow-ticketing-sir-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 roles listed in that tab, and set a password. You do not create REST API key records or access policies.

The same ITSM 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. 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 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. |


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` | Narrow incident create/edit via the ITSM Roles plugin (`com.snc.itsm.roles`) when admins prefer granular roles instead of the broad `itil` bundle; not contained inside `itil`. Usually redundant if `itil` is already assigned for incidents. |


`sn_incident_write` vs `itil`: ServiceNow treats these as separate. `itil` bundles many ITSM responsibilities (Incident, Problem, Change, and related permissions); `sn_incident_write` is a scoped incident write role shipped with the ITSM Roles plugin and is not inherited by `itil`. Activate `com.snc.itsm.roles` when your instance uses those granular roles. This guide's minimal bundle centers on `itil` because the incident flows commonly need that breadth plus supporting collections; if `itil` is already on the user, adding `sn_incident_write` is typically redundant for incident access. Least-privilege designs sometimes substitute granular roles such as `sn_incident_write` (with reads handled separately—for example `sn_incident_read`) instead of `itil`—only with administrator approval.

Assign the recommended minimal collections above (`itil`, `itil_admin`, `snc_internal`, and `personalize_decision_table_input`), 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 incident data looks incomplete or incorrect—for example, records are missing, fields you expect to update 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 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`, and `personalize_decision_table_input`, 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-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; use the lock icon to view it and copy the contents displayed below the field. Store it securely as you will need it for later steps.



### 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 role bundle in the [role-assignment tables in step 3](#ticketing-sn-token-roles) (`itil`, `itil_admin`, `snc_internal`, and `personalize_decision_table_input`): read, query, and patch are still governed by ServiceNow ACLs and roles on your instance. 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://<tenant>.service-now.com/`.

**Token**
Paste the REST API key value from [6. Create an API Key](#ticketing-sn-token-step-6-create-api-key) into the integration **Token** field.

If the integration still fails after entering these values, see [Troubleshooting](#troubleshooting-token).



### Troubleshooting

If the integration still cannot authenticate or load data after you save the integration, work through these checks with whoever administers ServiceNow—you do not need to inspect HTTP traffic yourself.

- Connection errors, "access denied," or an apparently invalid Token value: Paste the REST API key into the integration **Token** field again from [6. Create an API Key](#ticketing-sn-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 ([7. Set the API Access Policy](#ticketing-sn-token-step-7-api-policy)).
- Some 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`, and `personalize_decision_table_input`—see the [role-assignment tables in step 3](#ticketing-sn-token-roles).


If it still fails, your ServiceNow team can use Script/REST or transaction logs on their side to see why a call was rejected; contact whoever supplied this guide or your integration vendor for help interpreting errors.

Basic Credentials
HTTP basic authentication uses a dedicated ServiceNow user (username and password). Collections on that user define Incident table 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 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. |


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` | Narrow incident create/edit via the ITSM Roles plugin (`com.snc.itsm.roles`) when admins prefer granular roles instead of the broad `itil` bundle; not contained inside `itil`. Usually redundant if `itil` is already assigned for incidents. |


`sn_incident_write` vs `itil`: ServiceNow treats these as separate. `itil` bundles many ITSM responsibilities (Incident, Problem, Change, and related permissions); `sn_incident_write` is a scoped incident write role shipped with the ITSM Roles plugin and is not inherited by `itil`. Activate `com.snc.itsm.roles` when your instance uses those granular roles. This guide's minimal bundle centers on `itil` because the incident flows commonly need that breadth plus supporting collections; if `itil` is already on the user, adding `sn_incident_write` is typically redundant for incident access. Least-privilege designs sometimes substitute granular roles such as `sn_incident_write` (with reads handled separately—for example `sn_incident_read`) instead of `itil`—only with administrator approval.

Assign the recommended minimal collections above (`itil`, `itil_admin`, `snc_internal`, and `personalize_decision_table_input`), 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 incident data looks incomplete or incorrect—for example, records are missing, fields you expect to update 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 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://<tenant>.service-now.com/`.

**Username**
The service account from [2. Create a Service Account User](#ticketing-sn-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).