How can I reliably detect rate limit based 403 HTTP responses?

My interest is in being able to reliably distinguish between forbidden-due-to-too-many-requests vs forbidden-due-to-access-restrictions.

Unfortunately, the REST api returns “403” (forbidden) for rate limiting. (I realize it’s probably too late to switch to the more explicit “429” (too many requests) response.)

While this answer deals with the “single threaded” approach, I sometimes have concurrent scripts running (depending on event triggering).

Is there anything “guaranteed” to work? Or am I left to my own devices? :confused:

I haven’t worked as much with the GraphQL API – is the situation different there?

Thanks,
–Hal

Are there any clues in the actual response itself? Not familiar with the API, but I would assume there must be a way to tell. Maybe an extra response header?

Looking at the rate limiting docs, checking the X-RateLimit-Remaining header would make sense. If it hits 0 you’re out of requests. :wink:

Unfortunately, for search results, this is not true. (see answer linked in original post)

Yes, that’s the “ad hoc”, left to my own devices approach. I’d prefer to use a formally documented (hence supported) method.