Prevent 429 errors and quota exhaustion by configuring step-level rate limits, single-execution mode for workflows, and targeted backoff strategies for 429 responses.
Why Throttling Matters
Automation without throttling is like opening a firehose against a system designed for a garden hose. Most external APIs publish rate limits in their documentation — commonly expressed as requests per minute or requests per day — and exceeding those limits results in 429 errors that block your workflow. Even within Cotonity itself, each workspace has a concurrent execution limit to ensure fair resource distribution across all users. Without deliberate throttling, a single loop over a large dataset, a burst of webhook-triggered workflows from a high-traffic source, or a runaway scheduled job that stacks up because previous runs have not finished can all push you into these limits. Designing throttling into your workflows from the start is far easier than retrofitting it after a production incident.
Configuring Step-Level Rate Limits
For API steps inside a loop, the primary throttling control is the loop's concurrency level and the step's built-in rate limit setting. Open the API step's settings panel, scroll to Rate Limiting, and enter the maximum number of requests per second you want to allow. Cotonity's runtime enforces this limit by introducing automatic delays between step executions when the rate would otherwise be exceeded. Set this value to slightly below the target API's documented limit to leave headroom for other processes that might be using the same API key. For APIs with per-day quotas rather than per-second limits, calculate the average per-second rate your workflow consumes and set the limit accordingly — a workflow that calls an API 10,000 times per day needs to average no more than roughly 0.12 requests per second.
Workflow-Level Concurrency Controls
Some workflows should only have one active execution at a time — for example, a nightly database sync that would corrupt data if two instances ran simultaneously and wrote conflicting updates. In the workflow settings, navigate to the Execution tab and enable 'Single execution mode'. When this is on, if the workflow is triggered while a previous execution is still running, the new trigger is queued and runs when the current execution completes, rather than starting a parallel instance. Alternatively, choose 'Drop if running' to silently discard the new trigger if an execution is in progress — appropriate for idempotent poll-based workflows where missing a single run is acceptable. For workflows where some parallelism is fine but you want a hard cap, set the Maximum concurrent executions field to a number greater than one.
Monitoring and Responding to Quota Errors
Despite careful configuration, quota errors sometimes occur — especially when upstream systems change their rate limit policies or when a business event (a product launch, a marketing campaign) causes a sudden spike in trigger volume. Configure your error handling to catch 429 responses specifically and apply a longer backoff than your standard retry policy. Cotonity's condition step can inspect the response status code in the error branch to distinguish a 429 (back off and retry) from a 400 (bad request, do not retry) or a 500 (server error, retry with standard backoff). Review the Quota Usage dashboard in your workspace settings monthly to check your consumption trends and identify workflows that are disproportionate consumers of your execution budget before they cause problems.