Partnered Account for Testing Purposes

@fugiman it would also be great if subscribing to that channel was possible for free, with a free to define subscription date. Being able to unsubscribe would be a great touch too

1 Like

push :smile:
20characters :stuck_out_tongue:

Sorry to bump an old topic, but any resolution?

If anyone needs to test their code, you could use

This might not be the best way to test if the code is working as it should be but if you are good at what you are doing then you should be fine.

Twitch API documentation on Github provides some examples of what should be returned when making a call to the API. You could copy this example and paste it into to create some “dummy data” and then use the raw url for the pasted file to read the data from the file. If your code works with this “dummy data” then it should work with the partnered channels.

1 Like

I’d also get behind someone making a local server mimicking the Twitch API. I’d do it if I didn’t already have projects going on.

Local server would only run for your own project right? How will you provide access to it for other people that want to test their applications?

It would run on localhost, people could then download and run it on their own systems. Could be made in just about any language.

The biggest turn off I suppose is that it needs to be maintained along side changes to the API

The API doesn’t change much, if it does they release a new version so the old API still works but I agree that it would need to be maintained to make sure everything is up to date in case something does change.

Both in the partner category but also test account(s).
I am wondering if twitch has any intention of opening up the test_user1 or any other account. It would give developers an ability to create a “demo” user if they require a secondary login via twitch to grab, say the bio, the profile picture, if the user is partnered or the email. I know they could use their own, or use random data & bypass the secondary login for just that 1 account, I’m just asking.
E.g. my site checks if the user is partnered once they login and since the login stays active for 30 days and they could get partnered within that time, it also checks every time they update anything on their profile. With no valid oauth token it’ll throw an error that I have to write an exception for.

I notice this has been a while since last updated. I know this is what I need so I felt it was better to reply to this than to open an exact same thread again.
Has this been implemented? Or at least a way for developers to test partnered features? I’m using the Bits PubSub API and have no real way of working this without.
Edit: I noticed the link to test code to see if it works, but the problem is that I need a partner’s OAuth for this.

Thanks in advance!

Bumping ! It’s very hard to test bits and subs for a developer.

Or at least calling the API with a Test-Flag from a “Known Bot”-Account with a valid client id which results in a Trigger-Callback.


Still need some way to “Test Send” Special Twitch Events to Channel without being Partner/Affiliate

New Subscriber
New Giftsubscriber
New Anon Giftsubscriber


There’s no need to bump an over 2 year old thread. The correct place for feature suggestions is

Also, all of the testing functionality you’re asking for can already be done by creating mock data based on the documentation and testing your code using that mock data.

I think that’s a terrible excuse. Why should the user have to reconstruct the Twitch API and keep it up to date with the existing API?

Also, what happens if a user has local or automated github tests that will pass with their test cases, but because the API had an update, it fails in production? It’s maybe fine if you’re doing a quick test locally, but it doesn’t work in faster or more long-term environments.

There’s no excuse for Twitch to not have a sandbox for their API. They are one of the largest companies on earth and hundreds of smaller companies can do it, so why can’t they?

I created a User Voice since there wasn’t one that directly talked about a sandbox for the API as a whole:

Edit: Also, sorry I guess for reviving an old thread, but this was one of few talking about it, and I thought your idea was ridiculous.

You don’t have to “reconstruct the Twitch API”, you can literally copy/paste examples from the docs to use as mock data.

Twitch announce breaking changes to documented services well in advance, so there should be sufficient time to make any required adjustments to testing as needed. The vast majority of developers (ranging from new developers to larger organisations) have handled the rare occasions where there has been a breaking change to the API without issue.

Amazon may be one of the largest companies on Earth, but Twitch certainly isn’t, Creating what you’re suggesting isn’t some simple thing they can throw out there, it takes development time away from other features, and requires time and effort to maintain. Twitch may be working on such features already for all we know as this is nothing new what you’re suggesting, but just keep in mind this is far from essential or critical as the majority of developers have integrated with the Twitch API fine for years, and so would be prioritised as such when it comes to where they choose to focus their resources.

So let’s say I want to test the Pub/Sub API that requires a websocket connection and you to subscribe to specific topics.

Should the user be required to create a mock Pub/Sub API locally?

In your example, how would I have been able to figure out that I was not subscribed to a topic if I only copied the mock data?

So the burden of developing something for API testing should be pushed onto the API consumers, where the total combined time of maintain a mock API and time wasted from lack of proper testing would likely exponentially exceed the time Twitch would need to create a mock API?

Things like GET or POST endpoints don’t need it, Drops probably don’t need it, etc. So the only thing that really needs it is PubSub and the EventSub I guess. Is it that difficult to create a dashboard that taps into whatever services manage the Pub/Sub websocket connection to send events?

Also, the idea of writing code directly in your application just to test is silly. If the point is testing the Pub/Sub aspect of the API through a websocket connection, how would copying data directly into a variable solve that problem?

I guess if the consumer made their own websocket Pub/Sub server to mock the Twitch API, they could just swap out the twitch links for their local links in something like a dotenv file, but then what if you just wrote the wrong URL into the dotenv file or in your application’s config?

I get what you’re trying to say, but there really is just no excuse. Many other services that use Pub/Sub have testing on their end. I doubt that the cost to create maintain a testing environment, at least for their Pub/Sub where it is needed and has no other method to test than literally buying subs or bits is that significant.

This thread you continue to bump was made over 6 years ago. You’ve made a feature request, and I’d suggest voting for the existing ones, and if you want more information on best practices for testing and using mock data I suggest searching the forum and the dev discord as it is a topic that has been covered many times previously.

I searched the user voice and here for related topics.

User Voice only had one or two relative to API testing, and it was only for specific things. I upvoted one, but then made my own since I couldn’t find one relative to what I was suggesting, as the others were very specific to different parts of the API.

The forum goes to many posts relative to my topic (including this one), and many that aren’t super relative, but still about testing in general:

This thread we are talking in shows a staff member replying 6 years ago saying it’s a good idea, but with no response.

Here’s one where you were condescending to a user when they were clear in what they were asking.

Here’s another where you mention “which is quite trivial to meet the requirements of” in a condescending way. Should a developer really farm a Twitch account for days just to be able to test Affiliate features?

In this one, you mention:

…everyone has made do perfectly fine so far by just creating mock data based on the docs to test their functions.

Okay, people have “made do”, but is that really an excuse to stop asking for the feature when so many people want it and it would be a huge improvement in the API?

There is clearly a huge desire for this sort of functionality (since it is standard with almost every other API in existence). Or at least in the case of many APIs, making test accounts is easy and doesn’t cost anything most of the time if they don’t have a built-in functionality.

I’m not saying stop asking for the feature, I’m saying that Twitch are well aware that some devs have asked for it, and that UserVoice is the appropriate place to suggest such features and for developers to show Twitch what sort of demand there is for them.

You’ve made your voice heard, so there’s no need to keep repeating, and while this feature at some point in the future may help developers it doesn’t help developers right now who need to properly test their Twitch integration which is why it’s important to teach new devs how they can make use of mock data based on the documentation.