Are Per-IP 429 Errors Occurring on 'POST /v1/oauth/token'? What is the Recommended Auth Flow for Bursty Cold-Start Fleets?

This topic was automatically generated from Slack. You can find the original thread here.

hey hey

anyone hitting per-IP 429s on POST /v1/oauth/token recently?
started seeing them ~may 10 from server workloads (small egress IP pool). Same clientId/clientSecret:
• from my laptop → 200 OK
• from the worker → 429 with server: awselb/2.0, empty body
looks like an ELB-layer per IP cap rather than per-credential, since different PD projects hit the same wall

two questions:

  1. is /v1/oauth/token rate-limited per IP? i don’t see it on the Connect rate limits page
  2. recommended pattern for bursty cold-start fleets: is shared-bearer-across-processes the right move, or is there a better auth flow?
    using @pipedream/sdk@2.3.8

That is possible — can you tell me more about what kind of volume you’re sending to that endpoint?

would you mind DM’ing us your project ID / egress IP range so I can take a look? We did recently set lower rate limits on /v1/oauth/token and to Danny’s question - would love to know what kind of traffic you’d need to send there.

thanks! DMed to Dylan (we already discussing the issue)!

Posted thread to Discourse: Is the '/v1/oauth/token' rate-limited per IP and what is the recommended pattern for bursty cold-start fleets?

@U02A06JPKEH We are running into a similar issue here. We are being incredibly conservative in our implementation and still hitting 429s.

Our setup is as follows: we internally maintain a database with our active OAuth token (which has a 1 hour expiry). 45 minutes after acquiring the token (15 min before expiry), we attempt to acquire a new token every 5 minutes until successful. This means we are at most acquiring 1 token per 45 minutes. Even with that, we received 429s 6 times in the last 15 hours.

We are running on our services on Render. Is it possible that the egress IP range from Render is being rate limited as a whole? What do you recommend is a long term fix for this?

Is this still an issue? Are you using one of our SDKs or the REST API?

cc @U0ASSCRDDM2 can you help troubleshoot here?

Reviewing this now

Thanks guys, we worked it out (seems stable for the last few days)