> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.itential.com/adapters/configure/service-instance-configuration/properties/throttle-properties/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server. # Throttle properties > Reference for the adapter throttle object properties that control request queuing when an external system has load or concurrency limitations. All throttle properties are defined within the `throttle` object in theItential Platform service instance configuration for the adapter. Throttling is not commonly needed, but it is useful when an external system cannot handle high load or has concurrent license limitations. When throttling is enabled, the adapter queues requests and sends them to the external system at the rate defined by these properties. Only enable throttling when traffic has peaks and valleys. Valleys allow the adapter to drain the queue back to zero. If the queue never has time to drain, incoming requests will eventually be rejected because the queue is full. ## Properties | Property | Type | Required | Description | | ------------------- | ------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `throttle_enabled` | boolean | Yes | Enables throttling for the adapter. | | `number_pronghorns` | integer | Yes (if enabled) | Number ofItential Platform instances over which the throttle queue operates. Setting this to a value greater than `1` is currently non-functional; a fix is in progress. | | `sync_async` | string | No → `sync` | Reserved for future use; not currently active. | | `max_in_queue` | integer | Yes | Maximum number of requests to hold in the queue. Requests received when the queue is full are rejected immediately. | | `concurrent_max` | integer | Yes | Maximum number of requests that can be outstanding with the external system at any one time. The adapter tries to keep this many requests active while draining the queue. | | `expire_timeout` | integer | Yes | Time in milliseconds to wait after sending a request before sending the next one. This gives the external system time to free up a request slot or license. | | `avg_runtime` | integer | Yes | Expected response time from the external system, in milliseconds. Used as an initial seed for calculating queue wait times. The adapter replaces this with the rolling average of the last 25 actual requests as they complete. | | `priorities` | array | No | Priority rules for ordering requests in the queue. Each rule has a `value` (integer identifying the rule, matched against the `priority` field in the request object) and a `percent` (integer defining queue position as a percentage). A `percent` of `0` places the request first; `25` places it 25% of the way through the current queue. | ## Example This example allows five concurrent requests, queues up to 500 requests, and defines three priority tiers. ```json "throttle": { "throttle_enabled": true, "number_pronghorns": 1, "sync_async": "sync", "max_in_queue": 500, "concurrent_max": 5, "expire_timeout": 0, "avg_runtime": 400, "priorities": [ { "value": 1, "percent": 0 }, { "value": 2, "percent": 10 }, { "value": 3, "percent": 50 } ] } ``` In this configuration: * Priority `1` requests go to the front of the queue (`0%`). * Priority `2` requests are placed 10% of the way through the queue. * Priority `3` requests are placed at the midpoint (`50%`). * Requests with no priority value go to the end of the queue. > Reference for the adapter throttle object properties that control request queuing when an external system has load or concurrency limitations.