Client-ID Requirement FAQs

API
1

In case you missed it, the Kraken API will require a Client-ID as of August 8th, 2016. Read the blog for more details. Here are a few FAQs that I thought I’d address in one place:

Is the Client-ID required for all API calls?
Yes! Every API call, no matter how simple, will require the Client-ID in the header.

If I’m including an OAuth token, do I need to include a Client-ID?
If you are passing in an OAuth token, we will figure out the Client-ID for you.

Are query string parameters still supported for Client-ID?
Yes! We still support the query string parameter for the Client-ID.

Can I test to see if my Client-ID is being accepted?
Yes! We added the identified value to the root endpoint at https://api.twitch.tv/kraken. If this value is set to true, your Client-ID was accepted. If this value is set to false, your Client-ID wasn’t accepted. It’ll look like this:

Client-ID is correct:

AuthorizedClientId.png882×327 34.2 KB

Client-ID is incorrect:

7 Likes
3

Should I see the ‘identified’ keyword in the response to other calls such as https://api.twitch.tv/kraken/channels/myname/follows? Will they fail with the wrong Client-ID?

1 Like
4

You will only see identified at the root endpoint mentioned above. In August, the calls will fail if the Client-ID is incorrect on any endpoint.

1 Like
5

OAuth token alone seems to be considered identified. Is this correct?

Request headers don’t contain client ID either.

GET /kraken/?oauth_token=xxx HTTP/1.1
Host: api.twitch.tv
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.54 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,fi;q=0.6,sv;q=0.4

You can probably associate an oauth token with a client ID on your end, so I can see how/why this would be happening, but it goes against the idea of using the field as a means of verifying your client-ID sending.

1 Like
6

Yes, this is correct and your assumption was also correct. :slight_smile: We extract the client ID from the OAuth token that you sent in. What this means is that you can send Client-ID or the OAuth token, and we’ll be able to identify you. Depending on scope, not everyone needs an OAuth token, so this endpoint can support both Client-ID as a header and OAuth token standalone.

2 Likes
7

Will this be enforced even on somewhat static endpoints like /ingests?

Does this also affect the api.twitch.tv/api endpoint?

1 Like
8

All endpoints that start with api.twitch.tv/kraken will require the Client-ID headers. No exceptions. This also applies to api.twitch.tv/api.

Just a reminder: the only supported APIs at this time start with api.twitch.tv/kraken/. The others can change or go away without notice.

1 Like
9

Hi, could you clarify in the blog/forum post the relation between Client-ID and OAuth token ?
I’m currently using one endpoint, providing an oauth token. If i correctly understood your reply, it seems like I have nothing to change.

Your mail/blog/post would look a lot less alarming for people like me if you had made it clear from the start.

1 Like
10

@Spouwny The client ID is the string of numbers and letters you see when you register or edit one of your applications in your connections settings. It’s essentially the ID of your application.

OAuth token is an authorization token that will allow you, depending on the scopes, do various things on a user’s behalf via the API. One token is for one user on one application, so looking at the token Twitch can tell both the application it belongs to as well as the user who authorized it. (You can tell who authorized it as well by requesting the /kraken/ root).

If you’re already sending an OAuth token with your request, sending the client ID is optional since Twitch knows which application it belongs to.

1 Like
11

Thanks for your clarification, I understand the difference. Still the post need clarification in itself as it is clearly contradictory:

1 Like
12

Hello,

I have added Client-ID on every header, I just need informations about the link display on website for link user with an application :
https://api.twitch.tv/kraken/oauth2/authorize? … client_id=XXXX …

We need to add Client-ID on header for this url ? He is already in GET params.

Thank in advance.

1 Like
13

Yes, @DallasNChains, please clarify: You say:

you can send Client-ID or the OAuth token, and we’ll be able to identify you

but also

All endpoints that start with api.twitch.tv/kraken will require the Client-ID headers. No exceptions.

And I also need to know the answer to Nicolas_Ehrmann’s question, regarding if oath2/authorize needs Client-ID as a header when it is already supplied as the client_id query param. The third-party OAuth2 solution I’m using at the moment only sends the query param.

1 Like
14

@Nicolas_Ehrmann and @danbrakeley, your question is answered in the OP. We will continue to support the query string parameter:

To be clear about Client-ID and OAuth tokens: You have to send a Client-ID in the header or on the query string to get an OAuth token in the first place. Once you have an OAuth token, you can make a choice between sending the OAuth token or sending the Client-ID. Until you have a token, including the Client-ID is a must. The post erred on the side of having people include the Client-ID because that is the simplest and most common case. A lot of common use cases we hear about don’t make use of an OAuth token at all. In those cases, they just need to include that header and don’t need to go through the authorization flow.

I’ve updated the FAQ to include this question since it is now in the “frequently asked” category. :slight_smile:

4 Likes
15

Including the client_id in the URL on the https://api.twitch.tv/kraken/streams endpoint results in no output. This has broken many of my applications as I proactively went to update them with client_id support.

3 Likes
16

Moving the client_id functionality on /streams to from_client_id or something similar would be ideal, but it would break applications currently relying on the parameter. It definitely needs a way to pass the client ID from environments with no access to headers before the client ID requirement goes live.

1 Like
17

Ah, shit, yes, the official solution to get around that was to not provide a client_id when calling that endpoint, but that won’t work now…

1 Like
18

These changes are likely breaking a lot of applications already, so it would be an appropriate time to change it.

1 Like
19

We’re aware of the double usage of client_id on streams endpoints and will be removing the filter parameter to address the issue. For now, sending the client id as a header won’t trigger the bug.

2 Likes
20

Hi,
I’m getting "identified": false when calling the root endpoint with Client-ID header and/or client_id URL param.
This is happening with 2 different client IDs (copied from the connections page in twitch settings, so there are no typos)
Is there something else that should be done in order for the client ID to be identified?
Thanks.

2 Likes