If you’ve stumbled across this thread, i hope it is because you are a third party developer coming over to Twitch in the hopes of re-creating your integrations on this platform.
First and foremost: Welcome! We are an open community and are always listening to feedback and any questions you may have. A lot of things may not be 100% intuitive if you’ve never heard about them, so this Thread aims to collect information to draw Parallels between the third Party Developer offerings Mixer had and what Twitch has.
I myself never actually used Mixer, so feel free to correct me where i am wrong, but there should be some Info in here that’s useful for you.
First Things first: Authentication
Twitch also uses OAuth 2.0 and is compatible with at least some OAuth2.0 Libraries, i personally can confirm that the integration Postman offers functions 100% out-of-the-box.
If you are not using a library, having a look at the Auth Docs should have you covered, anyway. It’s just OAuth again.
An Important difference is that Twitch does not offer anything alike the “Shortcode OAuth” Mixer offers. Additionally, Twitch offers three types of OAuth Tokens, each are described here, but the general idea is that you want an App access token for Server-to-Server (i.e. your backend talking to the API) communication and User access tokens if you need access to any information that is privileged to any specific user. (Analytics data, for example.) Make sure to read about the different offered OAuth flows available - in addition to the Implicit and authorization code flows Mixer offers, there is also the client credentials flow to more easily get an app access token for your backend without any user prompt.
In general, you should find all the information you want to know in Helix, aka The New Twitch API. It is the parallel to the Mixer REST API. Note that there may be some information you are looking for that is simply not available either in Helix or at all. For the former, you may be lucky and still find it accessible in the deprecated Kraken v5 API, but you should avoid using it as it
was shut down at the end of 2018 will be shut down Soon™ and using it would double your migration efforts later down the road.
As for Helix you need to be aware that all Endpoints require a valid OAuth Token as well as your Client ID to be passed to it in the appropriate Headers (
Authentication: Bearer <TOKEN> and
Client-ID: <ID>, respectively), even if no specific scope is required for it. For details on Kraken, check out the docs. Don’t use it if you can avoid it.
One thing to notice is that there are a few commonly-used undocumented Endpoints, but i will not share them here as they are undocumented and thus can change at any time, without notice, without Twitch being required to provide any sort of replacement.
PubSub can be considered the equivalent of Mixer’s Constellation, but it is not JSON-RPC and does not offer as many “Events” as Constellation. You can find out what is available in the Docs. Instead of upon the initial connection, PubSub requires you to authenticate to each topic you want to listen to by passing the appropriate OAuth Token in the LISTEN requests. A single connection can listen to multiple topics of multiple different channels, but be aware of the mentioned rate limits.
Twitch’s Chat Interface is outward facing loosely based on IRCv3. It can be connected to via a plain IRC connection and most IRC libraries will parse it properly, but Twitch does not implement most of the Specifications’ available commands.
To join a chat room, simply connect and log in (noting the USER and PASS Syntax in the Docs), then
#channel - where
channel is the login name of the channel to join - this can be fetched from the API, for example. (For example, to join my chat, i would
JOIN #marenthyu. Be careful with non-ASCII display names.) Sending messages is as simple as
PRIVMSG as per the IRCv3 Standard.
ADDENDUM/EDIT: In contrast to Mixer, this also allows you to join multiple channels using a single connection - you’ll still want to use multiple connections after joining a reasonable amount of channels (depending on their size), but unless you are in multiple “big” channels, a single connection will suffice.
(Thanks to @TheElm for pointing out this difference!)
To receive more information about a message, you can request additional IRCv3 capabilities as listed in the Docs. These will add some nice-to-have contextual information as well as a few events that may not be available elsewhere.
Important to know is that the user list the IRC Interface provides is unreliable and should be avoided where possible. It may work for smaller channels, but is not even attempted to be provided for channels above 1k viewers. Refer to IRC update: removing MODE and NAMES capabilities for more info on this (and be on the lookout for a certain undocumented endpoint.)
On top of the bare-bones IRC interface, you may also connect to Chat using a WebSocket connection - this will add some overhead, but makes it accessible relatively easily in a Website context. Check your Developer console on a live channel to see how messages are encoded there. (They are still RAW IRC messages, but sent via WS and sometimes bundled up to have multiple messages in one payload.)
Well, Mixer has Webhooks, so does Twitch. Twitch follows the W3C WebSub specification, so you should feel right at home. If not, read the Guide.
Now for the big one: Extensions
Mixer has MixPlay.
Twitch has Extensions.
Thanks for coming to my TED Talk.
More seriously: The closest thing directly comparable to Mixer’s MixPlay is a Video-Overlay Extension. Twitch does not provide as much of a Framework for Extensions as Mixer has with “buttons”, but provides a powerful backend and a “Marketplace” (all extensions are free) for discoverability.
Every Twitch Extension is an HTML-iframe plus a Backend the third Party dev (you) provides.
Let that sink in for a moment.
Now, from what i have seen, MixPlays are generally well-embraced on Mixer and most people see and use them daily, which means they are quite prominent and each tries to be shinier than the next one, sometimes resulting in bad practices. This is (positively or negatively) opposite to the current Twitch environment - quite frankly, i personally rarely ever run into active Extensions that i actually want to use. Twitch Extensions are manually reviewed by Twitch Employees before they can be used by everyone and a lifecycle is enforced. This increases the quality of existing Extensions and enforces Guidelines.
A lot of viewers actually despise Extensions that “pop up” or permanently block the player view, so there are some/at least one popular Browser Extension that hides all Extensions. Try to design your Extension in a way that is not “annoying” to a first-time viewer.
This post has already gotten quite long, so i feel like i should submit it for now. There’s more details to be had on all of these topics, but the general takeaway should be: most things you had on Mixer have some sort of equivalent on Twitch. Don’t hesitate to ask questions, we’re here to help!
You can always ask questions here, in a different thread or simply join the third Party Developers Discord to get the attention of multiple people immediately. We’re a nice bunch! I promise! We don’t bite! We’re harmless! (Jokes aside, there are no stupid questions, so come and ask away!)
Others, feel free to add any details or good-to-knows that i may have missed!
Thanks for coming to my TED Talk.