Hey, developers!
We have a new Developer Agreement that hopefully helps with some of your open questions around the API. For more context, we’ve published a new blog about why we’re releasing this and how everything is presented.
This thread is for feedback and any comments.
Thanks,
Dallas
Thank you! This is very much appreciated.
Might be a good idea to have these assets in a more readily accessible location. Right now I believe they are only linked on the JS SDK Github repo and are not included on the general Brand Assets page.
Seems a bit vague, and quite a few people are asking what it is or how to get one. I personally understand it to be simply an account that has an application associated with it, according to section 4.
Where are they asking this? This is the first time I’ve had this question. Not sure if I’m missing a contingent of confused people. 
Your interpretation is correct. Any account with a registered Developer Application is considered a Developer Account.
On the /r/Twitch Discord Server. There was quite a bit of confusion in the #developers room when the announcement when out, thanks for clearing it up 
IV.B. Keys … you will be issued one or more unique security keys, secrets, tokens, access codes, passwords or other credentials (collectively, “Keys”). … All activities that occur using your Keys are your responsibility. Keep them secret.
That would mean, that I can’t give out my Client Id, therefore I can’t use it to make valid Twitch API requests on frontend.
It would be extremely inconvenient. It would make all websites unable to use Twitch API without proxying all the requests.
Can I use Twitch API with Client Id in my website?
Regardless authorization process exposes Client Id to anyone trying to login to my app.
Given that I have at least publicly available authentication to my app, anyone can get my Client Id and impersonate me.
Will my app get rate limited if someone would abuse Twitch API rate limit using my Client Id?
I have a couple points I would like cleared up if possible.
IV.C. Rate Limits
“You will not attempt to exceed or circumvent limitations on access to and use of the Program Materials, exceed or circumvent any limitation on the API calls you may make…”
Does this affect using multiple websocket connections to chat to get around the chat message limits that would otherwise ban bots that operate in many channels?
SCHEDULE 1
Storage of Program Materials/Twitch Content
In the previous ToS I recall that there was a part about not storing data obtained through the API about twitch users for more than 24 hours unless they sign up to your app. Which from my interpretation meant not storing things like how long a user has been in chat for unless they sign up to the app. There doesn’t seem to be the same point in this ToS, it has the same rules about users having the right to delete any data about them when asked, but I don’t see it restricting storing data about users in chat regardless of if they have signed in to the app or not. So before I start recording that for all users rather than just some (to provide bonuses/achievements to long timer viewers), can I please get confirmation that doing that would be okay under this ToS?
ClientID is public, it is your responsibility to secure your ClientSecret which can be used in the oauth flows and register to your application. Collectively, across the board in all OAuth applications ‘ClientID’ is public. While the ClientID associates a request to your application it is not secured information - Anybody can use it to make a request. While I can’t speak to rate limiting based on abuse on the ClientID, that section is talking about items you are expected to secure, and not share.
@tournymasterbotCurse Thanks for clarification. Maybe I missed something, but it wasn’t obvious for me when I started using Twitch API. Maybe it should be clearly communicated?
Either way I am still very curious on official position on rate limiting and possibility of malicious 3rd party use of Client Id.
@asterius @tournymasterbotCurse has it right. For abuse, we would work with you if that happened to ensure your service is OK and to block the bad actor. We’ve yet to see a case where this has happened (although it isn’t out of the realm of possibility).
@Dist In general, the 100/30s rate limit is plenty enough even for the largest bots. If you have a good use case for your bot exceeding that rate limit, you should contact us directly for whitelist consideration. Most bots hardly ever exceed the rate limit.
For your second question, the data storage restriction clause was: “Twitch user data for users not created by your application may be stored for no more than twenty-four (24) hours.” That means no user data could be stored for more than 24 hours regardless of signing up. This is still in effect but more broadly worded and with the ability to set up an agreement with Twitch. Check out the third bullet and the (a) clause under the Storage of Program Materials/Twitch Content section.
Thanks for all the great questions! It’s helping us guide our thinking about how we can clarify these issues. 
Unfortunately due to the risk of a bot being unmodded while taking advantage of the increased 100/30 limit most multi-channel bots are forced to stay under the 20/30 limit for each connection.
The only reasonable solution to the ratelimiting issue is to turn the 100/30 limit into a per-channel limit that does not account for slash commands like /timeout or /ban.
Even the smallest (!) bots that run in even a single channel, can run into issues. Thanks to very inconsistent and uncommunicated changes to the systems (slash commands used to be included in the limit, then not, then again and currently I believe they dont count), we are forced to always dynamically maintain a number of connections to prevent ourselves from being IP banned.
And experience has shown that whitelists have always been unreliable at best. Most of the time, they are maintained for a week or two and then forgotten about forever, potentially being removed without notice at any given point in time.
I’ve had several cases where a single chat required more than 100 timeouts to be sent within 30 seconds (nl_kripp reached as much as 380-something once about a year ago). Add to that the issue that you have to send 2 timeouts per message to ensure it gets deleted due to race conditions on the client-side and the fact that multi-channel bots can’t rely on the 100/30, like @george mentioned, and you have a real problem on your hands.
Additionally, I’m having to send ~24 messages a second just to keep /mods lists somewhat reasonably updated (a little under 24h).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.