ServiceNow Dev Pro never asks for your ServiceNow password. You connect with a ServiceNow API key. This guide covers every field you have to fill in.
(A second, browser-based sign-in mode exists in the plugin’s code but ships disabled by default in 2026.1.0 — it is not selectable in Settings in this release, so it is not documented here.)
The following mechanics were verified against a live ServiceNow instance on 3 August 2026: the API Key auth profile table (http_key_auth) and its Auth Parameter field; the generic Inbound Authentication Profile form’s missing Auth Parameter field; the stock Table GET/Table POST API Access Policies shipping inactive, with no stock PATCH policy; the access policy’s Authentication profile requirement; the plugin’s GET/POST/PATCH-only method usage (and what Apply to all methods additionally grants); the seven required tables; and the com.glide.tokenbased_auth plugin. Additionally verified on 6 August 2026: the Step 1 plugin-list deep link itself (confirmed to return exactly the “API Key and HMAC Authentication” plugin, active); the sys_token_auth_parameter_list row for x-sn-apikey (confirmed Internal Name “Header for API Key”, Type “Auth Header”); and the http_key_auth new-record form’s Auth Parameter and Application fields (confirmed Application defaults to Global). Everything else below — exact menu paths, a handful of field labels, and confirmation-only side steps — is documented to the best of our knowledge but was not independently re-confirmed in either pass; each is marked ❓ where it appears. Replace YOUR-INSTANCE in the links below with your own instance (e.g. dev12345).
Setting up your API key
Three records plus a plugin check — five steps, in this order. Skipping or misordering them is the usual cause of a 401.
Step 1 — Check the plugin is active
Open All → Admin Center → Application Manager and search for API Key and HMAC Authentication (com.glide.tokenbased_auth). If it is not active, activate it. Nothing below exists until it is.
❓ The exact menu path is documented to the best of our knowledge, not independently re-confirmed in the 2026-08-03 pass — only the plugin’s ID/name and active/inactive state were.
Quick check (a different, faster UI — the plugin list filtered by name/ID, not the Application Manager module itself): https://YOUR-INSTANCE.service-now.com/v_plugin_list.do?sysparm_query=idLIKEtokenbased%5EORnameLIKEAPI+Key+and+HMAC
com.glide.tokenbased_auth. The query string above is URL-encoded to match exactly what the plugin’s own button sends.Step 2 — Create the API Key auth profile
http_key_auth).
Go directly to: https://YOUR-INSTANCE.service-now.com/http_key_auth.do?sys_id=-1
| Field | What to enter |
|---|---|
| Name | Anything descriptive, e.g. ServiceNow Dev Pro (IDE) |
| Auth Parameter | Select Header for API Key. This is the built-in parameter whose value is the x-sn-apikey HTTP header — the header the plugin sends. Do not pick “Query Parameter for API Key”. |
| Application | Leave as Global |
Verified on 6 August 2026 against a live instance: the new-record form has exactly these two fields (Name, Auth Parameter) plus Application, which defaults to Global as shown, and a related list below the form (“Authentication Policies”) that isn’t part of the fields you fill in here.
Click Submit.
To confirm what “Header for API Key” actually means, open https://YOUR-INSTANCE.service-now.com/sys_token_auth_parameter_list.do — you should see a row with Parameter Name x-sn-apikey, Internal Name Header for API Key, and Type Auth Header. Verified on 6 August 2026 against a live instance.
Step 3 — Create the REST API Key
Go to: https://YOUR-INSTANCE.service-now.com/api_key_list.do → New
Prefer a dedicated least-privileged user over admin — the key acts as that user, so everything the plugin does is limited by that user’s roles and ACLs; it does not grant any permission the user doesn’t already have. On a free PDI you’re the only user anyway, so admin is a reasonable default, but on a shared or corporate instance, create (or ask for) a service account scoped to only what this plugin needs — read/write on the tables in Step 4 — rather than pointing the key at an admin account.
| Field | What to enter |
|---|---|
| Name | e.g. ServiceNow Dev Pro key |
| User | A dedicated least-privileged user if you have one; admin works on a PDI but is not least-privilege. |
| Active | Ticked |
| Expiry | Recommended as a rotation control, not just a limit. Set a date, note it somewhere (or put a calendar reminder on it) so you rotate the key before it lapses — the plugin will start failing with 401 the moment it does. |
❓ These exact field labels (Name, User, Active, Expiry) reflect the api_key form as documented, not individually re-confirmed in the 2026-08-03 pass.
Save, then copy the generated key value. ServiceNow shows it once. Paste it into the plugin’s API key field.
Step 4 — Enable a REST API Access Policy (Table API) ← the usual cause of a 401
A valid key is not enough. An access policy must grant it access to the Table API, and ServiceNow ships the Table API policies switched off.
Go to: https://YOUR-INSTANCE.service-now.com/sys_api_access_policy_list.do
On a stock instance you will find Table GET API Access Policy and Table POST API Access Policy with Active = false. Open a Table API policy and set it up with least privilege — grant exactly the methods this plugin uses, nothing more. Neither stock policy covers PATCH; a stock instance ships no PATCH policy at all, so you must add PATCH to a policy yourself. Browsing works without it, pushing does not.
| Field | What to set |
|---|---|
| Active | Tick this. If it is false, every request returns 401 no matter how good your key is. |
| REST API | Table API |
| HTTP methods | Cover GET, POST, and PATCH — the plugin never uses PUT or DELETE. GET is for browse/open, POST creates the sys_user_preference row that stores your current Update Set, and PATCH is for push. Leaving any of the three uncovered fails that operation. |
| Apply to all methods | A shortcut, not the recommended path. It also grants PUT and DELETE, which this plugin never uses. Prefer naming GET/POST/PATCH explicitly (or separate policies covering each) over ticking this box. |
| Authentication profile | Set this to the API Key auth profile you created in Step 2 — without it, the policy does not accept your key. |
Tables the policy must allow:
| Table | Why |
|---|---|
sys_script_include | Script Includes |
sys_script | Business Rules |
sys_script_client | Client Scripts |
sys_ui_action | UI Actions |
sys_user | Resolves who you are — powers the Modified by me browse scope and Update Set selection. Omitting it degrades both silently, with no error. |
sys_update_set, sys_user_preference | Required to list Update Sets and set the current one |
Step 5 — Test
In the IDE: Settings → Tools → ServiceNow Dev Pro, enter your instance URL and the key, click Test connection.
What’s stored locally, and how to remove it
Credentials. Your API key is stored in IntelliJ PasswordSafe — the IDE’s own credential store, backed by your OS keychain by default (macOS Keychain, Windows Credential Manager, Secret Service/KWallet on Linux). ServiceNow Dev Pro never writes it to a plain-text file, a log, or anywhere under your project. To remove it, click Clear stored credentials in Settings → Tools → ServiceNow Dev Pro. Your instance URL is not a secret and is kept with your other plugin preferences in the IDE’s own settings file — clear it by emptying the field and clicking OK.
Local script files. Pulling a script creates a local working copy under <project>/.servicenow-dev-pro/. That’s ordinary project-directory content, not something PasswordSafe or the IDE manages. The plugin writes a .gitignore containing * inside .servicenow-dev-pro/ the first time it creates that folder, so its contents stay out of version control by default even though it lives inside your project — but uninstalling the plugin does not remove the folder itself. Delete .servicenow-dev-pro/ yourself if you want it gone.
Nothing is sent anywhere but your instance. ServiceNow Dev Pro talks only to the ServiceNow instance URL you configure. No analytics, no telemetry, no third-party service ever sees your credentials or script content.