Cams - Chaturbate API V2 parsing via JavaScript
 

Have you wanted to build your own cams page from the Chaturbate API?

This is a little bit of code to help get you started.

It is based around Chaturbates API Version 2.

The biggest change between Version 1 and Version 2 was that Version 2 wants the client IP to be passed in on the API request. This allows Chaturbate to filter the results based on what cams they allow to be shown in what region.

With Version 1, the most common usage is to pull the results of the API server side and then cache it there, either as a file or in a database. Then dole out the results from the cache on each page hit. Typically you would do a pull from Chaturbate every 2-5 minutes to keep the cams fresh.

With Version 2, it is expected that you will pull from the API on every page hit with the client ip for filtering. This means that instead of hitting the API once every 2-5 minutes, you are hitting it on every page hit. This is considerably more overhead for your server to handle.

The solution? Move the API handling onto the client side. How do you do that? Using javascript and/or jquery.

The following code is the javascript I came up with to do the API call and parse in the client's browser. It has been tested in Chrome, Opera and Firefox. It is a simple little bit of code that for most practical uses must be expanded upon. It will work as is but really should have other things with it, things like a design and text, ya know? All those cool web things.

I am listing 2 different ways to pull in the API. The first is pure javascript, the second uses a jquery call to the AJAX object. To use the jquery version you need to include the jquery libraries. If you are already using jquery on your pages then it makes the most sense to use the jquery version. However, if you do not use jquery, are trying to keep your page load as low as possible, or are just a minimalist at heart, then you might want to use the pure javascript version.

Either way, there are 2 parts.

Part 1 is pull in the API data.

Part 2 is parse the API data and display it.

I have included some comments in the code to help you figure out what is happening but I left some for you to figure out yourself. I am including in here 2 working demos for you to view. Look under the sheets, play with the code.

The code is running from a .php file. You could almost do all of this with pure javascript but unfortunately you cannot get ahold of the user's ip in javascript. You either have to grab it from your server or from a 3rd party service. I decided that the best way to grab it was from my server and I use php to accomplish that. Since I am already in a php file I decided to utilize a little more code to make the solution a little more dynamic.

Have fun.


.

Example 1 - Using Javascript for the ajax api call:

https://madspiders.com/demo/cb_apiv2_demo1.php

Example 1 source code:

Example 2: Using jquery for the ajax api call:

https://madspiders.com/demo/cb_apiv2_demo2.php

Example 2 source code:

For the record the <base href tag is not actually part of the source code. GFY is inserting that into the post.

.

sarettah to the rescue as always, big thumbs up ;)

Nicely done :thumbsup

Great stuff, sarretah knows his shit.

Thanks for posting this. We encourage all affiliates to use the new API where possible.

FYI when calling from the client side, you do not need to pass the ip, you can just set it to "request_ip".

Please see our documentation (chaturbate[dot]com/affiliates/promotools/api_usersonline/) for more information.

https://i.imgur.com/dTQH9iZ.png

We love you, sarettah . . . even though you hate us.

Nice! I need to do more with cams, traffic for me has been going up. :upsidedow

Thanks for that. I will make a note of it.

Here is the link for the docs (You really need to post more there Kitt. Get up there above 30 posts so you can post links and show us your tits and all that). https://chaturbate.com/affiliates/pr...i_usersonline/

You need to be logged in to chaturbate to read the docs

Don't have a Chaturbate account? You can sign up here with my ref code https://www.camfoxes.com/webcams/webmaster_signup.htm

Or you can sign up directly at Chaturbate https://chaturbate.com/affiliates/

Bith links load real slow tright now so please be patient.

What?? When did I ever say I hated you (or anybody).

You are one of my favorite posters.

.

The Chaturbate link in my sig loads faster, so I think people should use that one instead. :upsidedow

Hmm. I was just putting together a new demo using the info that Kitt provided.

During testing I noticed that it loaded really slowly.

So, I went back and looked at the other 2 demos I posted and they are now seeming to take a while to load, about 15 seconds.

Earlier they were popping right in.

Don't know if the api is running slow or what the issue is.

I just know it was working fine and now it is a slow load.

.

Some of the cams on the main site aren't loading right now, either. The splash comes up but then a constant spinning load animation. Then once in a while when I refresh, it loads but then like 3fps.

Sample using just javascript - no php. Using request_ip in the client_ip parameter.

https://madspiders.com/demo/cb_apiv2_demo3.htm

Source:
As I said in the previous post, right now the api seems to be coming back slower than it has been. Still looking to see if it is my problem or on their end.

.

Yeah but you aren't real well known for that thinking stuff.

.

You're thinking of Colmike7

I try not to think of any of you.

.

Still happens, tho :winkwink:

All the demos seem to be working fine now.

That is one of the problems of pulling teh api every hit, you become a slave to the api.

If the data from the api is stored on the server then you can reload the old data again when the api pull fails.

Might be a way to delay clearing the page on a hit so that you could check for a good return but I am not sure what that way would be at the moment. Have ot think on that.

.

I just had a conversation with another programmer (whom I respect very much). He had seen the code and suggested a couple of changes in the .php versions of the code.

When getting the ip I was simply using the Server var for the Remote Ip ($_SERVER['REMOTE_ADDR']).

He suggested that for someone hosting with a forwarding service, such as cloudflare, that the Remote Addr var would always return Cloudflare's ip.

So to get to the real ip we have to do a little shuffling through the various server vars we have available and the code ends up looking something like:

He also reminded me to always escape the server vars as a security step.

So I am changing up the 2 php demos to utilize this methodology.


Thanks to K0nr4d (https://gfy.com/members/k0nr4d/) for the advice. https://www.mechbunny.com/ is Konr4d's baby if you did not know that already.



.

https://madspiders.com/demo/cb_apiv2_demo1.php

Demo 1 new source code:

.

https://madspiders.com/demo/cb_apiv2_demo2.php

Demo 2 new source code:

.

Cloudflare has their own headers for you to substitute into your code. REMOTE_ADDR is HTTP_CF_CONNECTING_IP.

Thanks WOTY :thumbsup

.

So based on what Fuzebox said, if you are hosting on cloudflare and were doing this with php you would want to check for Cloudflare's custom server var (HTTP_CF_CONNECTING_IP) for handling the ip.

.

Any plans for disabling API v1?

Sarettah you are the best! Thank you for sharing this with us! You already helped me and other people a lot around here :thumbsup

Can you tell me what is the advantage of using API version 2? Because version 1 is quite functional, and there is no such "problem" with ip.
Thank you

First of all the disclaimer: I am NOT an employee of Chaturbate, I am an affiliate just like the rest of you.

I do not know what advantages Chaturbate intended on v2 versus v1.

I can tell you the advantages I see, but it will be totally from my perspective.

V1 was never really (imho) intended to be pulled on every hit. It returns all cams every time you call it. Each time it is called you have to process through the entire set of cams to do the various things you want to do.

V2 allows several passins that limit the return set.

limit= controls the number of records coming back
offset= controls where in the return set to start
exhibitionist= I am not sure what that will do, have not explored it yet,
gender= allows you to select a single gender or all genders
region= allows you to return cams for just a certain region
tag= returns records for certain tags
hd= returns records for hd cams

Then there is the client_ip parameter. This allows Chaturbate to filter based on a performers setting whether the cam should appear in the set based on the users country or locality. Version 1 has a field for countries allowed but it has always been empty. If it was filled it would have been up to you to do a lookup by ip to see if the user on your site should see the cam or not. This should eliminate some of the issues of putting a cam up and when you click it coming back saying that you are not allowed to see it.

These new parameters allow you to more finitely control the return set. It also allows the api to be much more efficient in that it does not have to be returning as many records and you don't have to handle as many records. So, with V2 you can realistically call it on every hit and still have a fast site.

There are disadvantages too. With Version 2 it is harder to do certain things. For example, I have several sites that are based off the age of the model (18yearoldcams, 1821camgirls, milffoxes(coming)). To do those with V2, using it the way it is intended, would be a major pain in the ass as there is no pass in to return just certain age cams. I would have to circumvent what Chaturbate wants to do and still use V2 like it was V1, pulling it into the database so that I could spit out just the cams I want.

I also like to do certain sorts. By age, location, etc. Doing these effectively with V2 would be another PITA. You would have to pull in all cams, sort them and then present the proper set. So again, I would probably be circumventing Chaturbate's intended use of V2 and instead use it as I use V1 and load it all to a database every 5 minutes.

Another disadvantage showed itself yesterday. While I was making this thread, the api slowed down for some reason. This made all my demos break basically. I don't have to worry about that on the sites I am loading using V1. On those I load a database. If the API does not return for me I just use the old set of cams until the API comes back. I am never without cams. That is not true if you are using V2 on every hit. On V2, you are basically presenting what is in the api return, no api return, no cams. I am sure there will be workarounds to handle that but using it as intended, there is not.

I think V1 will still has it's place and there are so many sites using it that I doubt that Chaturbate will be turning it off anytime soon. I have a note in Chaturbate right now asking if they have a planned end of life date on V1 as I use it all over the place.

That is my take on it for what it is worth and I guarantee that it is worth every cent you paid for it.

Edited in: I forgot to list what might be the biggest advantage although I did mention it in the OP. With V2 you can create a workable client side only solution. V1 did not really allow that because of the overhead involved in handling all the cams on every api call. Since you can limit the number of cams on V2 through the various passins you can create a client side solution that works. This moves a shitload of infrastructure and bandwidth off of your server and on to the client. This should result in lower costs and more efficient page delivery.

.

I heard that those are accounts who just want to show off and not asking for tips. Seems weird lol.
*I also heard it was for accounts that are also not age verified yet, which also seemed weird. Maybe the article I read is wrong, idk.

Not sure but I did a test a few minutes ago. Set limit to 10 and set exhibitionist to true, got 1 record back.

So, of all the thousands of cams on line at that time only 1 was marked exhibitionist so I don't know that the parameter is significant.

.

I have a few cam sites using the API for each request so they use no database at all. Can such sites be theoretically faster then using a site + local sql database? Or only in cases when my server is really shitty slow or gets a ton of request and can't handle them properly?
One of my best performing site in search engines gets data from the API alone, so no local caching etc.

If you're using v2 to pull into a database, what IP do you use? The server IP?

I notice a distinct delay on my webcam page using API v2, of about 2 seconds or more - and I'm only getting a list of 40 cams. I want to eliminate this by going to a database driven approach, only trouble is my site is aimed more at UK and European visitors so those are the cams I pull out of the API, but my server is in the US. So that's not ideal.

My guess is that it would definitely be possible for a site just using the api to be as fast or faster than a site pulling the whole thing into the database.

First of all there are efficient ways to do things and inefficient ways. If someone has coded the api call and parse propely and is doing pagination then that could be a very fast site. However if they are doing just the api and trying to present all the cams all at once then it will probably be a slow load.

On the server side solution, the database has to be designed properly and the sql calls need to be coded properly. Just because something is in a database does not mean it is fast or efficient.

There is a lot of shitty code out there, I know because I have written some of it.

.

I have not played with v2 on the server side so I am not sure what the best workaround would be yet. My gut instinct would be to hardcode my home ip in the client_ip field and use it that way but without playing with it some I could not give you a good answer.

.

0.0.0.0 to avoid geo IP filter

That would appear to work. Thanks for that :thumbsup

So, redwhiteandblue, there is your answer.

.

Yeah I'm definitely calling the API with limit+page and tags where needed (subcategory pages). It's pretty fast..

You are talking about API V2 then?

I thought you were talking about V1. But with V2, yeah, definitely can make a site run faster then going into a database or caching scheme. Less infrastructure to deal with. Less steps involved.

I am going to set up dudefoxes using full client side javascript. Only call back to the server will be the click into the cams because I want to hit my tracking script (oh and the logo and crap like that).

.

No-no, I'm talking about AWEs Video Promo API.. I havent checked CHBs API v2 yet

@sarettah this is very cool and wicked fast.

How could chat_room_url_revshare and image_url be modified to reflect a white label URL without slowing it down?

Otherwise adblock.

You shouldn't have to touch image_url. From what I see it is the chat_room_url that triggers the block.

You can modify the Chat room url ot pull from a whitelabel by just using:

Whitelabel + Username

So something like this (using my whitelabel at Hot Foxes at Camfoxes.net to link to):

txt +='<a rel=nofollow style="color:#000000;font-weight:bold;" href=https://www.camfoxes.net/' + xmlDoc.getElementsByTagName("username")[i].childNodes[0].nodeValue + '>';

Where I was using the chat room url from the feed before.

This appears to get past my adblockers and works on opera with ad blocking turnded on no problem:

https://madspiders.com/demo/cb_apiv2_demo4.htm

.

Ah, when you mentioned limit and tags I just assumed. My bad.

Thanks

.

Thanks Sarettah.

As a learning project I intend to use this to replace the WP Live Cam Wordpress theme I have running on a domain and it's huge Gigabyte size DB....

I started in on 2 new sites yesterday using the pure javascript version.

Still have to do up some text and change up colors and shit but they are up and running.

https://dudefoxes.com

https://milffoxes.com


Still have to doctor them up for mobile too.

.

Figured out the pagination today. Works pretty slick.

.

2 pages of cams