Client-ID Requirement FAQs

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 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:

Client-ID is incorrect:


Should I see the ‘identified’ keyword in the response to other calls such as Will they fail with the wrong Client-ID?

1 Like

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

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
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

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.


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

Does this also affect the endpoint?

1 Like

All endpoints that start with will require the Client-ID headers. No exceptions. This also applies to

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

1 Like

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

@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

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

1 Like


I have added Client-ID on every header, I just need informations about the link display on website for link user with an application : … 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

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 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

@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:


Including the client_id in the URL on the endpoint results in no output. This has broken many of my applications as I proactively went to update them with client_id support.


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

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

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

1 Like

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.


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?