How to send back a Retry-After response header with 429

[timothy_park]

I was looking at the docs and it’s pretty clear how to configure an API to send back some additional headers and how to use the plugin middleware to modify the response as well, but it doesn’t look like there’s any obvious way to just set a retry-after header that indicates how many seconds the client should
wait before retrying their request. I would like it to look something like this, with the 10 indicating 10 seconds:

"Retry-After": "10"

I ran into a couple of problems with testing.

First, if I add a global_rate_limit to an API, it looks like it returns a 429 before hitting my custom auth_check plugin. I believe the documentation is congruent with that, so does that mean if I have an API configured with a global limit, there’s no way to modify the request before Tyk just returns a 429 with the standard headers?

Second, I tried creating a custom plugin to tinker around and see if there was anything in the session metadata that might indicate when a key was going to hit a limit and it doesn’t seem obvious to me. Is there some context variable or session variable that stores how many requests a key is still able to make within the allowed rate limit window?

Tyk Version: 5.3.1

// tyk.conf rate_limit config
  "enable_non_transactional_rate_limiter": true,
  "enable_sentinel_rate_limiter": false,
  "enable_redis_rolling_limiter": false,

[Olu]

@timothy_park

First, if I add a global_rate_limit to an API, it looks like it returns a 429 before hitting my custom auth_check plugin. I believe the documentation is congruent with that, so does that mean if I have an API configured with a global limit, there’s no way to modify the request before Tyk just returns a 429 with the standard headers?

Well you can modify the request within the Pre-Request Middleware (Plugin) level but there is no way to change the response header when it hits the rate limiter.

You can use the errors template to modify the body or message if you are interested

We have an enhancement request internally to populate Retry-After header when 429 is issued in the backlog. The internal reference is TT-6084. I can update this thread once the feature has been implemented.

@timothy_park

Second, I tried creating a custom plugin to tinker around and see if there was anything in the session metadata that might indicate when a key was going to hit a limit and it doesn’t seem obvious to me. Is there some context variable or session variable that stores how many requests a key is still able to make within the allowed rate limit window?

No there is no context variable or session/key that indicates the rate limit remaining

[Olu]

@timothy_park On second thought you may want to check out if request throttling can handle what you want