Bump. I have this same question. However, I get <Response [202]> even when I put an invalid callback url. I’d appreciate if someone could help clarify what’s going on.
After you subscribe to the webhook, Twitch send send a GET request to your callback URL with hub.challenge as a querystring parameter, this is to confirm your callback is reachable and active (thus, why you can’t use localhost, as localhost to Twitch is their own servers so would serve you no purpose), all you have to do at this point is respond with that same hub challenge.
After that has been successfully done, just wait. When there is a notification, Twitch will send a POST request to your callback URL with the data in the body, the data will have the exact same structure as the underlying API topic. When you receive a notification, respond with a 200, otherwise Twitch’s assumes delivery failure and attempts redelivery with a growing backoff timer.
it is also HIGHLY recommend that you use a hub.secret when subscribing, as this will allow you to confirm all notifications have come from Twitch, otherwise there’d be nothing stopping some random user who has found your callback URL from just POST’ing data to it. An example of how I handle this with express is:
As long as the URL is internet accessible and you have set up to handle incoming GET and POST requests from Twitch, then yes it’s usable as a callback.
But after a while in response to a request comes a message about exceeding the frequency of requests. Why does this happen if the limit is 120 requests per minute, and I only do 12?
You need to have a service of some sort running on the callback URL that is listening for HTTP GET and POST requests. That’s how webhooks perform the initial subscription process and then when sending notifications.
If you’re just using Client ID and not a Bearer token in the request, the ratelimit is 30, not 120. If you’re still hitting the rate limit you must be doing more than 30 requests a minute. Also, requesting any API point that frequently is excessive as all endpoints use caching, so you will be getting back the same cached data needlessly.
These are the authentication docs. For any endpoint that doesn’t require authorisation you can follow the docs to obtain an App access token, if the endpoint does require authorisation then you need a User access token. When you provide one of these tokens in the header of the request you’ll have a ratelimit of 120/min
As for the repeated requests, send the request once a minutre rather than every 5 seconds.
If I do this:
If an error occurs, the bot will take a pause for 10-30 seconds, and then start making requests again.
In this case, the period of one request is 5 seconds.
Is it possible to do so?
Like I said, don’t request every 5 seconds. it’s pointless as you’re just getting the same cache back, and in some situations you can actually get odd results by polling that frequently because if a stream just goes live, you may get lucky on one request that says it’s live, but on the next request the stream may still show as offline as that cache server you hit didn’t have an up to date record. This means when you poll that excessively there’s a greater chance to flicker between versions of the cache until they reach consistency.
So like I said, poll once a minute, if there’s some error then handle the error and resend the request.
Webhooks can be the most ideal way to get stream status as it waits for consistency between the API servers before sending the notification. There is some delay, but they’re working to minimise it. If you must know exactly when a stream goes live, then neither polling the API or webhooks is the solution for you.