Rate limiting for workflows

The rate limit is the maximum number of requests that you can make to webMethods Integration in a span of one minute. The rate limit works at the tenant level and is applicable to manually run, trigger-enabled, and webhook-enabled workflows.

How rate limiting works

webMethods Integration employs two different rate limiting mechanisms for workflows based on their type.

Rate limiting for sync webhook-enabled workflows
Rate limiting for manually run, trigger-enabled, and async webhook-enabled workflows

Rate limiting for sync webhook-enabled workflows

Sync webhook-enabled workflows are the ones, which contain the Return Data on Sync Webhook action. This action is used to send the workflow output in the body of the webhook URL.

For sync webhook-enabled workflows in webMethods Integration, the webhook URL structure is https://[tenant-address]/runflow/run/sync/[workflow-id], where

[tenant-address] is the base URL of your webMethods Integration tenant. For example, env9755329.a-vir-r2.int.ipaas.automation.ibm.com).
[workflow-id] is the unique identifier of the specific workflow.

Rate limit condition for paid plans - Sync webhook-enabled workflows: Under paid plans, if you send execution requests for more than 1500 sync webhook-enabled workflows within a minute, the first 1500 requests are processed while the rest of the requests are rejected. In such a case, you need to send the execution request for the rejected workflows again.

Note: Although the specified rate limit is 1500/minute for sync requests, you must avoid sending all the requests within a short span of time, such as 1 - 2 seconds. To help ensure the availability of resources and to avoid unexpected failures, best practice is to distribute the requests within a time span of 60 seconds.

Rate limit condition for trial/unpaid plans - Sync webhook-enabled workflows

Under trial/unpaid plans, if you send execution requests for more than 30 sync webhook-enabled workflows within a minute, the first 30 requests are processed while the rest of the requests are rejected. In such a case, you need to send the execution request for the rejected workflows again. When a workflow request is rejected, you receive the following data in the response header. So, you can use these details to design your APIs and resend the execution requests.

"Retry-After": <retry_after_time>
"X-RateLimit-Limit": <total_requests_allowed>
"X-RateLimit-Remaining": <total_requests_remain>
"X-RateLimit-Reset": <next_limit_start_date>

Rate limiting for manually run, trigger-enabled, and async webhook-enabled workflows: The rate limiting mechanism for manually run, trigger-enabled, and async webhook-enabled workflows, that is, workflows that do not contain the Return Data on Sync Webhook action, varies from the sync-webhook enabled workflows.

Rate limit condition for paid plans - Manually run, trigger-enabled, and async webhook-enabled workflows: Under paid plans, if you send execution requests for more than 15000 manually run/trigger-enabled/async webhook-enabled workflows within a minute, the first 15000 requests are processed while the rest of the requests are rejected. Such workflows have a Failed status against them in the Monitor > Workflow Execution screen.

Note: Although the given rate limit is 15000/minute for async requests, you must avoid sending all the requests within a short span of time, such as 1 - 2 seconds. To help ensure the availability of resources and to avoid unexpected failures, best practice is to distribute the requests within a time span of 60 seconds.

Rate limit condition for trial/unpaid plans - Manually run, trigger-enabled, and async webhook-enabled workflows: Under trial/unpaid plans, if you send execution requests for more than 300 manually run/trigger-enabled/async webhook-enabled workflows within a minute, the first 300 requests are processed while the rest of the requests are rejected. Such workflows have a Failed status against them in the Monitor > Workflow Execution screen.