How to Give Your Integration a Static IP for ServiceNow (IP Access Control)

If your ServiceNow integration authenticates correctly but still gets refused, or works from your laptop and fails once deployed, the cause is usually an IP restriction on the instance. ServiceNow lets administrators allow only specific source IPs, and that applies to REST integration accounts, not just interactive users. Your cloud platform does not give you a stable IP to register, so the fix is two static IPs you add once. For inbound callbacks, regional options, and the full reference, see the ServiceNow static IP docs page.

ServiceNow's IP Restriction Blocks Rotating Integration IPs

ServiceNow has two customer-controlled ways to restrict access by source IP. IP Address Access Control, under System Security, allows and denies access by IP range across the instance. REST API Access Policies, under System Web Services, can restrict API access by IP, role, or group, scoped to specific REST APIs. When either is active, a request from an address not on the allowed list is refused, even when the credentials are valid. A document-sync job, a workflow automation, or a custom app on a cloud platform egresses from an address that changes on deploys and scaling, so it gets blocked.

QuotaGuard Static Gives You Two Fixed IPs to Allowlist

QuotaGuard Static is an HTTP, HTTPS, and SOCKS5 proxy on AWS. Every account is assigned two static IP addresses behind a load balancer, and those two IPs do not change. You add both to ServiceNow's allowed set, route your integration's calls through the proxy, and every request reaches ServiceNow from one of those two addresses regardless of how your hosting platform rotates underneath. Your two IPs are shown in your QuotaGuard dashboard after sign-up.

Add Your QuotaGuard IPs to ServiceNow

This is done by a ServiceNow administrator. For instance-wide control, open System Security, then IP Address Access Control, and add Allow rules for your two QuotaGuard IPs. ServiceNow blocks an address only when a Deny rule matches and no Allow rule matches, and Allow rules supersede Deny rules. For API-scoped control, add your IPs to the relevant policy under System Web Services, then API Access Policies. ServiceNow will not let an admin lock themselves out, so confirm your own access is covered before relying on a Deny-all rule.

Set Your Proxy URL as an Environment Variable

Store the proxy URL from your dashboard as an environment variable on your integration's host, next to your ServiceNow credentials.

QUOTAGUARDSTATIC_URL="http://username:password@us-east-static-01.quotaguard.com:9293"

The us-east in that host is the region you selected at sign-up. Pick the region closest to your ServiceNow instance, and contact support to change it later, since you cannot swap it by editing the connection string.

Route Only the ServiceNow Calls Through the Proxy

Attach the proxy to the requests that reach ServiceNow rather than forcing all traffic through it. The ServiceNow Table API lives at https://your-instance.service-now.com/api/now/table/{table} and accepts OAuth 2.0 or Basic Auth.

In Python with the requests library:

import os, requests

proxies = {
    "http": os.environ["QUOTAGUARDSTATIC_URL"],
    "https": os.environ["QUOTAGUARDSTATIC_URL"],
}

instance = "your-instance"
resp = requests.get(
    f"https://{instance}.service-now.com/api/now/table/incident",
    params={"sysparm_limit": 1},
    auth=(os.environ["SNOW_USER"], os.environ["SNOW_PASSWORD"]),
    headers={"Accept": "application/json"},
    proxies=proxies,
)
print(resp.status_code)

In Node.js, native fetch ignores a proxy agent, so use node-fetch with https-proxy-agent.

const fetch = require('node-fetch');
const { HttpsProxyAgent } = require('https-proxy-agent');

const agent = new HttpsProxyAgent(process.env.QUOTAGUARDSTATIC_URL);
const instance = 'your-instance';
const auth = Buffer.from(`${process.env.SNOW_USER}:${process.env.SNOW_PASSWORD}`).toString('base64');

const resp = await fetch(
  `https://${instance}.service-now.com/api/now/table/incident?sysparm_limit=1`,
  { agent, headers: { Authorization: `Basic ${auth}`, Accept: 'application/json' } },
);
console.log(resp.status);

If you use OAuth instead of Basic Auth, request a token from https://your-instance.service-now.com/oauth_token.do and route that call through the proxy too, so the token request also exits from your static IPs.

Verify Your Integration Is Using the Static IP

curl -x "$QUOTAGUARDSTATIC_URL" https://ip.quotaguard.com

The response returns the IP your request came from. It should match one of the two static IPs in your dashboard. Once both are in ServiceNow's allowed set, a call that previously returned a 403 will succeed.

Regulated Data Belongs on QuotaGuard Shield

If your ServiceNow data includes regulated records, use QuotaGuard Shield instead of Static. Shield uses SSL passthrough and never decrypts your traffic at the proxy. For standard ITSM integration traffic, Static is the right choice. Static tunnels your outbound HTTPS without decrypting the payload, so it is appropriate for most ServiceNow work.

QuotaGuard Static Pricing Starts at $19/Month

Bandwidth is bundled, with no per-GB overage fees. The Starter plan at 20,000 requests and 10 GB per month covers a typical integration. Production is $49 per month, Business is $89, and Enterprise is $219 with dedicated IPs and 1 TB of bandwidth. On the lower tiers your two IPs are static but shared. All plans include a trial, 3 days on standard tiers and 7 on Enterprise, with a credit card required. See the full table at quotaguard.com/products/pricing.