Introducing the Twitch PubSub System

Hey, everybody!

We’ve posted our new Twitch PubSub System documentation GitHub. You’ll find a general overview and guidelines for using PubSub as well as Bits-specific topic information. We’re going to be adding more topics to the PubSub system over time. :slight_smile:

Let me know if you have any questions!

-D

4 Likes

Is there any info on what kind of topics are going to be added in the future?
Are for example followers or subs/resubs under consideration?

Nothing to share at this time. We’ll update the doc set as we add topics! :slight_smile:

Interesting, hope to see more contributions to see the possibilities of what can be done with this.

What’s the required scope to listen to whispers and bits events?
I generated an oauth token with all documented scopes and I still get ERR_BADAUTH

Bits should be able to use any scope. Are you not seeing that behavior? Whispers isn’t publicly supported over PubSub at this time.

I haven’t tried the bits events yet actually because i don’t have an oauth token linked to a channel with the bits feature.
Why is such a token necessary though? Isn’t everyone on IRC able to get that information as well without having a token linked to the channel?

But good to know that whispers aren’t supported yet.

PubSub has access to extra data not available in chat messages. With that in mind, we require a channel token for user privacy reasons. :slight_smile:

Absent an API sandbox (or web socket sandbox), can we have better examples as to the actual examples that will be received from the pubsub server? (Specifically, better examples of [BODY] content.

I would also like to request a new feature: Version

{
    Type (string)
    Version (int)
    Data (dynamic)
}

The new item ‘Version’ is just an incremented integer whenever the data model changes for the dynamic body (Data). This will allow for smooth transitions between versions, where the old parsers can remain in place for old data, and new data can be cleanly handled. The version incrementing will also be an alert for developers that they need to review the data model changes for any actions required to match the current version.

[Personally I would like this for all api endpoints, but I’ll settle with baby steps for now]

What do you mean by better examples, @tournymasterbotCurse? Is there something missing from the Bits message documentation? Good feedback about version! I’ll pass it along to the team. :slight_smile:

Looks like it’s mainly just expecting too much from the introduction page, specifically I was looking at this:

Receiving messages

Clients that have listened on a set of topics will receive message streams to those topics.

Message Parameters

Name	Type	Description
type	string	Set to 'MESSAGE'.
data	JSON	Wraps the `topic` and `message` fields.
topic	string	The topic the message is being sent on.
message	string	The body of the message.
Example message

{
  "type": "MESSAGE",
  "data": {
    "topic": "video-playback.lirik",
    "message": "..."
  }
}

When really I was expecting something more like this in the “message”: “…” section

Receiving a Bits event message

When a message for your subscription is published, you will receive a message containing the applicable data. The message will look like the following:

{
    "type": "MESSAGE",
    "data": {
        "topic": "channel-bitsevents.XXXXXXXX",
        "message": {
            "user_name": "dallasnchains",
            "channel_name": "twitch",
            "user_id": "...",
            "channel_id": "...",
            "time": "2015-12-19T16:39:57-08:00",
            "chat_message": "Omg that baneling bust was Kreygasm cheer10 cheer10 cheer100",
            "bits_used": 120,
            "total_bits_used": 620,
            "context": "cheer"
            }
    }
}

(The bits example is perfect for the message)

Specifically, since you’re requesting the topic "topic": "video-playback.lirik" I am looking for the message data response for ‘video-playback.lirik’. This could be a bad expectation on my part, it just seems like a confusing example when you’re reading about it as an introduction page.

Though the confusion would go the other way, with a provided example body someone might assume that’s the only message type you can receive from that endpoint… so idk.

Maybe the easiest solution is to just mention somewhere in text ‘message format comes from the specified topic, please refer to the topic endpoint documentation.’’?

That totally makes sense. I removed the message contents for brevity on the top level page. I definitely think a note of, “Each message property is specific to an individual topic. Refer tot he topic endpoint documentation for the full expansion.”

Just to be clear, at the moment the only topic that is available for subscription is the Bits topic?

@the_manufactory: That’s the only supported topic, yes. As other devs have found, there are other topics available, but they’re not officially supported (much like the tmi.twitch.tv and api.twitch.tv/api endpoints). We’ll keep the docs updated as we add them to the supported list.

@DallasNChains

Can we have better examples for the following? [Just had to answer some questions related to it]

REF: https://github.com/justintv/Twitch-API/tree/master/PubSub


// Request from client to server
{
  "type": "LISTEN",
  "nonce": "44h1k13746815ab1r2",
  "data": {
    "topics": ["whispers.test_account","video-playback.lirik"],
    "auth_token": "...",
  }
}
// Response from server to client
{
  "type": "RESPONSE",
  "nonce": "44h1k13746815ab1r2",
  "error": "",
}


This should really be something more like



// Request from client to server
{
  "type": "LISTEN",
  "nonce": "44h1k13746815ab1r2",
  "data": {
    "topics": ["whispers.23161357","video-playback.23161357"],
    "auth_token": "...",
  }
}
// Response from server to client
{
  "type": "RESPONSE",
  "nonce": "44h1k13746815ab1r2",
  "error": "",
}

and a description that 23161357 = Lirik’s channel ID

Or something like on the bits page, and have a nice little box the explains each parameter name/description for the request

Do you mean this, @tournymasterbotCurse? https://github.com/justintv/Twitch-API/tree/master/PubSub#request-parameters

Bits is the only supported topic for PubSub, so we won’t expound on the video playback topics until we support them publicly. I may even change those examples to use Bits examples to avoid confusion.

Essentially anything that requires a numeric channel id, instead of a channel name should use an example numeric value. .XXXXX (as shown in the bits example) was confused with needing to use the channel name because of the examples on the main pubsub page.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.