@MaheshPopudesi, ok, just to be double-sure: So we can still check for header X-RateLimit-NearLimit to detect if less than 20% of the hourly quota is left?
@matthias and @scott.dudley Thank you for highlighting this
This is exactly the direction we’re heading. The structured format was designed with this kind of consolidation in mind, unifying rate limit policies into a single set of headers. We’re leading with points-based quota limits first, and will progressively bring other limit types into this format going ahead.
1 Like
Hi @matthias
The X-RateLimit-* headers will continue to be used for burst rate limits and per-issue rate limits, they’re not going away. For points based quotas we will use the new Beta-RateLimit and Beta-Ratelimit-policy to give you clear view of points usage and tiers (RateLimit and RateLimit-policy at enforcement) And, yes Retry-After will be returned. If your app already respects Retry-After, you’re in good shape for both burst and quota enforcement.
I will circle back on the other questions.
1 Like
Yes, X-RateLimit-NearLimit will continue to indicate when less than 20% of your hourly quota remains. At enforcement, you’ll also have the new RateLimit header with the r (remaining) parameter which gives you the exact number of points remaining as well when 20% of the hourly quota remains. We recommend planning to migrate to the new headers, but X-RateLimit-NearLimit will keep working and we’ll publish guidance on any future deprecation timeline.
1 Like