ServiceNow provides powerful REST APIs to integrate with external systems, but like any enterprise platform, it enforces rate limits to ensure performance, stability, and fair usage across tenants. This article breaks down the core concepts of rate limiting, throttling, and how to plan for API consumption effectively.
Key Concepts of Rate Limiting
1. Rate Limits Per Instance or Node
ServiceNow REST API performance is governed by a combination of system resources and subscription-based limits. While your licensing tier and node count define the maximum number of requests your instance can handle over time, the actual throughput per second is influenced by dynamic factors such as concurrent sessions and the availability of semaphores.
Semaphores are internal controls that manage how many transactions can run in parallel. When transactions are long-running or complex, they occupy these resources for longer periods, which can slow down or delay new incoming requests. If the system becomes saturated, it starts queuing transactions. Once the queue reaches its limit, additional requests may be rejected—typically with an HTTP 429 Too Many Requests error.
Because of this behavior, it's difficult to define a fixed number of requests per second that any instance can reliably handle. Instead, throughput varies depending on the volume, complexity, and duration of each request.
To manage this, ServiceNow enforces rate limits based on your subscription type and node count, which help ensure fair usage and system stability across all tenants.
Typical Limits:
• Per Instance: ~100,000 requests/hour (Enterprise plans)
• Per Node: ~25,000 requests/hour (Varies by licensing)
• Burst Limit: ~50–100 requests/second depending on performance tier
Example Throughput Planning:
Plan Type |
Approx Requests/Hour |
Requests/Second |
|---|---|---|
|
Small Instance |
25,000 |
7 |
|
Medium Instance |
50,000 |
14 |
|
Large Enterprise |
100,000+ |
28+ |
2. Concurrent Requests & Throttling
ServiceNow uses semaphores to manage concurrent transactions. If these are saturated, the system may throttle or queue incoming requests.
Limits (Example):
• 10 concurrent API threads per node
• Default Semaphores: 16
• Semaphore Queue Depth: 150
• Max Concurrent Transactions: 166
• Explanation: This example configuration allows a maximum of 166 concurrent transactions, 16 active + 150 queued = 166 concurrent transactions. Then, the 167th transaction will be rejected with an HTTP 429 error. Requests may also return HTTP 202 Accepted if queued
You can monitor semaphore usage at:
https://<INSTANCE>.service-now.com/stats.do
3. Handling Throttling & Errors
When limits are exceeded, ServiceNow may respond with:
• HTTP 429 – Rate limit exceeded
• HTTP 202 – Request accepted but pending execution
Best Practices:
• Implement retry logic with exponential backoff
• Ensure third-party systems can handle 429 responses
• Avoid flooding the instance with simultaneous REST calls
Viewing & Configuring Rate Limits
You can view or configure rate limits using the sys_rate_limit_rules table:
https://<INSTANCE>.service-now.com/sys_rate_limit_rules_list.do
Create custom rules based on your integration needs and licensing agreements.
Inbound vs. Outbound API Quotas
Inbound Calls:
• No hard quotas, but subject to performance limits
• Throttling may occur under high load
Outbound Calls:
• No quotas unless using IntegrationHub
• For Integration Hub limits, refer to: IntegrationHub Licensing
Further Reading & Resources
-
Azure discovery throwing "429 Too Many Requests" errors [KB0961758]
Final Thoughts
Understanding and planning for ServiceNow REST API limits is essential for building scalable, resilient integrations. Always monitor usage, implement smart retry strategies, and consult your account manager for licensing-specific thresholds.
We hope this article has been useful. If it truly addressed your needs, please consider marking it as helpful. If not, we’d greatly appreciate your feedback so we can improve and better support our community. Feel free to reach out with any questions.
Thank you!
#servicenow #workflow #automation #rest #soap #api #limit #concept #bestpractice #outbound #inbound #call #integration
Kind regards,
Luis Estéfano
