Problem
Organizations frequently consume APIs that impose request limits. Currently rate limiting must be implemented manually in individual workspaces.
When multiple:
- HTTPSCallers
- Workspaces
- Jobs
- Engines
access the same API simultaneously, the combined traffic may exceed API limits and trigger throttling responses.
Proposed Enhancement
Introduce configurable rate limiting at one or more levels:
-
Workspace Level
- Limit requests generated by a specific workspace.
-
Connection Level
- Limit requests for all requests using a particular Web Connection.
-
Flow Instance Level
- Global rate limiting across all jobs and engines.
Potential configuration examples:
- 100 requests/minute
- 10 requests/second
- Burst allowance
Example Use Case
Several scheduled workspaces consume the same business-critical REST API. Each workspace individually remains within limits, but the combined execution volume exceeds the provider's threshold, causing failures and retries.
Benefits
- Reduced API throttling
- Improved reliability
- Simpler workspace design
- Better enterprise API governance
Additional Note
Some APIs return HTTP 429 (Too Many Requests), but many APIs either implement custom throttling behaviour or provide limited feedback. Centralized rate limiting in Flow would protect these integrations proactively.