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.

## Generating Credentials

REST API keys are preferred when your instance supports them (**Washington DC** or later). The **Token** tab walks through the full ServiceNow sequence (plugin, inbound authentication profile, REST API Key record, REST API Access Policy)—then you paste the REST API key into Synqly's **Token** field. The **Basic Credentials** tab is shorter: create a service user, assign roles from that tab's Roles section, and set a password. The same ITSM role collections apply in both tabs; only authentication differs. Basic credentials do not replace a REST API key if your team asked for one.

Token (recommended)
### Roles for ITSM incidents (REST API key path)

Synqly authenticates Table API requests 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; assign collections on the integration user in step 4 using the role-assignment tables immediately before that step.

For Synqly HTTP paths, see [Ticketing accessed provider endpoints](/guides/connectors/ticketing/accessed-provider-endpoints).

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

**Role assignments**

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


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 |
|  --- | --- |
| `sn_si.manager` | Security Incident Response (`sn_si_incident` and related SIR data), not only the standard Incident table. |
| `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 Synqly's 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.

Choosing a minimal bundle—open the scenario that matches your scope (stack these when multiple apply):

Standard ITSM only
Assign: `itil`, `itil_admin`, `snc_internal`, `personalize_decision_table_input`, plus the custom role from step 3 when you use step 8 or admins require it.

Skip unless needed: `sn_si.manager`, `u_ticket_user`, `admin`

With SIR
Add: `sn_si.manager` for Security Incident Response (`sn_si_incident` and related SIR data), on top of the standard bundle.

Otherwise: treat optional collections like the Standard ITSM only scenario unless another tab applies.

Custom ticket table
Add: `u_ticket_user` when extended ticketing tables such as `u_ticket` are in scope—not only standard Incident.

Combine with Standard ITSM only and/or With SIR as needed.

Webhooks / automation
Add: `admin` or the least-privilege role your admins define when automation touches `sys_script`.

Combine with the other scenarios when applicable.

Authentication works but incidents look wrong—missing, read-only, hidden fields, failed status/`sys_choice` labels, or SIR failures while standard incidents work—usually points to roles or ACLs, not the REST API key wiring. Re-check the tables and scenario tabs above (including `personalize_decision_table_input` and `sn_si.manager` for SIR) and any 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 tables and scenario tabs above—typically `itil`, `itil_admin`, `snc_internal`, and `personalize_decision_table_input`, plus any optional collections when they apply (for example `sn_si.manager` for SIR). See [Roles for ITSM incidents (REST API key path)](#roles-for-itsm-incidents-rest-api-key-path) when choosing bundles.

### 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 [Roles for ITSM incidents (REST API key path)](#roles-for-itsm-incidents-rest-api-key-path)—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—you will paste it into Synqly's **Token** field.



### 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**. For Synqly, 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 [Roles for ITSM incidents (REST API key path)](#roles-for-itsm-incidents-rest-api-key-path) (`itil`, `itil_admin`, `snc_internal`, `personalize_decision_table_input`, and optional `sn_si.manager` for SIR): 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 [Create an API Key](#ticketing-sn-token-step-6-create-api-key) into Synqly's **Token** field.

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

h3
Troubleshooting (Token)
If Synqly 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 Synqly's **Token** field again from [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 Synqly 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-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`, `personalize_decision_table_input`, and `sn_si.manager` if you use Security Incident Response—see [Roles for ITSM incidents (REST API key path)](#roles-for-itsm-incidents-rest-api-key-path).


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
### Roles for ITSM incidents (basic credentials path)

Synqly uses HTTP basic authentication with a dedicated ServiceNow user (username and password). Collections on that user define Incident table access for Synqly. Complete step 1, then assign collections on the integration user in step 2 using the tables immediately before that step.

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

For Synqly HTTP paths, see [Ticketing accessed provider endpoints](/guides/connectors/ticketing/accessed-provider-endpoints).

### Basic credentials — 1. Log in to ServiceNow as an Admin

Navigate to **All > Organization > Users**.

**Role assignments**

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 |
|  --- | --- |
| `sn_si.manager` | Security Incident Response (`sn_si_incident` and related SIR data), not only the standard Incident table. |
| `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 Synqly's 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.

Choosing a minimal bundle—open the scenario that matches your scope (stack these when multiple apply):

Standard ITSM only
Assign: `itil`, `itil_admin`, `snc_internal`, `personalize_decision_table_input`, plus any custom ACL role admins defined.

Skip unless needed: `sn_si.manager`, `u_ticket_user`, `admin`

With SIR
Add: `sn_si.manager` for Security Incident Response on top of the standard bundle.

Otherwise: treat optional collections like the Standard ITSM only scenario unless another tab applies.

Custom ticket table
Add: `u_ticket_user` when extended ticketing tables such as `u_ticket` are in scope.

Combine with Standard ITSM only and/or With SIR as needed.

Webhooks / automation
Add: `admin` or the least-privilege role your admins define when automation touches `sys_script`.

Combine with the other scenarios when applicable.

Authentication works but incidents look wrong—missing, read-only, hidden fields, failed status/`sys_choice` labels, or SIR failures while standard incidents work—usually points to roles or ACLs. Re-check the tables and scenario tabs above (including `personalize_decision_table_input` and `sn_si.manager` for SIR) and any ACLs your administrators added.



### Basic credentials — 2. Create a Service Account User

Select **New**. Fill in the required fields, including **Internal Integration User**.

Once the user exists, open it, select **Edit...** on **Roles**, and assign collections using the tables and scenario tabs above together with [Roles for ITSM incidents (basic credentials path)](#roles-for-itsm-incidents-basic-credentials-path).

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.

### Basic credentials — 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 [Basic credentials — 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).