RELATED IDEAS
Retry rate-limited app requests
App requests can be rate-limited and, if they are, they are never retried automatically. Rate-limit errors are inherently retry-able, so Front should be able to retry them safely, which should drive up workflow success rates.
-
ADMIN RESPONSEAug 7, 2026
Your idea is now live and open for voting.
Strong +1 on this.
Rate limits are a property of the third-party service, not of how a workflow is configured. No amount of trigger tuning or rule design on the customer's side prevents them, which means this is one of the few failure modes an admin genuinely cannot engineer around inside Front.
The consequence may not just be a failed run or a comment added to a conversation. When an app request is the step that writes to a system of record, a dropped call means Front and that system quietly diverge, with no signal until someone notices the data is wrong or a downstream action doesn't happen. That gets harder to catch as more of this work is handled by agents rather than people: an agent won't flag the gap, it will act on the stale record, and the error compounds from there.
Automatic retry on 429 is standard behaviour for integration platforms, and its absence is a fair thing to weigh when deciding how much automation to keep in Front versus external middleware. Keeping it in Front is the better outcome for everyone.