local_rate_limited

[post04]

I see no mention of local_rate_limited here. I have a lot of info on it that I can contribute.

For simplicity, I'll be saying LRL. So LRL seems to be a somewhat new thing to the API, you can see some mentions of it in march of 2022 but that's only on the official v2 API, besides from that, this change from what I'm aware is brand new to the v1.1 and graphql (gql) API's, or at least added within the past 3 months. You can request to almost any endpoint to trigger it. All you need to do is request on >15 threads for >5 minutes or so. You'll see that at some point you start getting response code 429's with bodies that say local_rate_limited. You should note that any X-Rate-Limit headers will not be indicative of you hitting a rate limit.

With that being said, here's how you should think of LRL. This is basically a thread limit. For as long as I've been using twitter's API, I've never seen a proper attempt at a thread limit be implemented and I think they've finally added one.

Let's go back to what I said earlier though. I said, "You can request to almost any endpoint to trigger it." This is because, from my research, I've found a few endpoints that don't have this LRL and I think I've figured out what they all have in common.
https://twitter.com/i/api/1.1/friendships/create.json
https://twitter.com/i/api/graphql/5V_dkq1jfalfiFOEZ4g47A/CreateTweet
https://twitter.com/i/api/graphql/ojPdsZsimiJrUGLR1sjUtA/CreateRetweet
All three of these are immune to LRL, and all three of them don't return any X-Rate-Limit headers. I'm not sure this is intended at all, the endpoints don't have any rate limit expected but I don't see any reason they should bypass LRL protections. Either way, that's how it seems to work from what I've noticed. I've not yet been able to force any endpoints that typically give LRL and X-Rate-Limit headers to not return those but that would be pretty neat regardless and this would be the way to do it.

Thanks for reading!