After some rigorous testing (by spamming the API), I figured out the rate limits for the follow-up endpoints.
- 5/2s per interaction
- 30/60s per guild/global (hard to test)
Since all these endpoints use the application_id as their webhook_id parameter, the major parameter is incorrect in this case. The new major parameter seems to be interaction_token then.
I'm asking if there is a specific reason why the application_id was used for these endpoints, instead of using the interaction_id? This design makes the handling of these endpoints rather annoying and I would much prefer if they also used the interaction_id instead.
Otherwise, this behavior should be documented explicitly somewhere since it heavily deviates from the documentation right now. If libraries would handle application_id the same way as webhook_id then the rate limit handling would only allow 5 messages per 2 seconds globally.
After some rigorous testing (by spamming the API), I figured out the rate limits for the follow-up endpoints.
Since all these endpoints use the
application_idas theirwebhook_idparameter, the major parameter is incorrect in this case. The new major parameter seems to beinteraction_tokenthen.I'm asking if there is a specific reason why the
application_idwas used for these endpoints, instead of using theinteraction_id? This design makes the handling of these endpoints rather annoying and I would much prefer if they also used theinteraction_idinstead.Otherwise, this behavior should be documented explicitly somewhere since it heavily deviates from the documentation right now. If libraries would handle
application_idthe same way aswebhook_idthen the rate limit handling would only allow 5 messages per 2 seconds globally.