Implement rate limiting in a workflow

💬 Workflows
,
1

I am creating a public app that will send out a 2FA code using Twilio resource. This is all done in a workflow.

I’m worried about a possible Toll Fraud Attack whereby an attacker will use a script to call the workflow on repeat causing millions of messages to be sent out via my Twilio account causing me big financial loss.

As far as I can see, retool doesn’t provide any rate limiting for workflows. So, i’m looking to roll my own into the workflow.

Initially, i was going to do this using IP Address but, it can’t seem to get the client IP address (only retool’s server IP).

I was hoping someone had a solution?

1 Like
3

Hi @amarcus85,

I do unfortunately believe that is a limitation for workflow webhook triggers.

Since the requests are hitting another retool server first and then hitting the workflow executor, the IP address is going to be accessible at the first server but not passible to the workflow unless you build out all that infrastructure on a self hosted instance :sweat_smile:

My best suggestion for a work around would be if you self-host Retool, to deploy behind a proxy or API gateway (e.g., Nginx, Cloudflare, AWS API Gateway, or Traefik).

Other options include Using Cloudflare or AWS API Gateway

If your Retool instance is exposed via a custom domain:

  • Cloudflare → enable Rate Limiting Rules or WAF custom rules to cap requests by IP or path.

  • AWS API Gateway / ALB → wrap the Retool Workflow endpoint behind the gateway and configure throttling policies (e.g., 10 requests/sec per IP).

  • No infra changes to Retool

  • Logging, alerts, and automated blocking possible

Implement a manual limiter in the Workflow

If you can tolerate soft limits, you can add logic inside the Workflow:

For example:

  1. Add a Retool Postgres or Redis resource.
  2. At the start of your Workflow, log each request with a timestamp and client identifier (e.g., IP or token).
  3. Query how many requests that client made recently.
  4. Abort if over a threshold:
if recent_requests > 10:
    raise Exception("Rate limit exceeded")

Pros:

  • Flexible and customizable

Cons:

  • Doesn’t stop traffic at the network level
  • Still consumes Workflow execution capacity
1 Like
4

Hi @amarcus85,

I just wanted to circle back on this and see if my suggestions were helpful!

We don't fully provide rate limiting functionality to workflow although I believe that is a feature request ticket the engineering team currently has.

For work arounds, self hosted deployments have some options for using load balancers and cloud hosted deployments would likely need some more inventive work around in the Retool workflow logic to enact some control over rate limits.