How To Integrate Web Sites with YouTube’s API — A Simple Example Using PHP

Screenshot from Youtube.

Most web sites utilize YouTube for marketing purposes these days (or at least they *should*). Integrating videos is fairly straightforward, too; YouTube wouldn’t be where it is today if it hadn’t made embedding videos on web sites and on social media extremely simple and straightforward.

That said, when YouTube becomes a major aspect of a business’ marketing (and, I’m talking about managing a growing list of hundreds or thousands of videos), then managing the web integration in a more sophisticated way can offer benefits for a web site. So, I wanted to cover that in a fairly broad way, but also show some basic examples of how to do it in a way most site owners are as aware of.

If you’re a web developer, the entire article should interest you. If you’re a business owner interested in ROI, I recommend skipping to the end where I offer advice on whether it makes sense to consider pursuing a Youtube API integration with your web site.

Initial Goals: Scalability

Broadly speaking, what we’re after when approaching video management for a web site is scalability, whether via coding best practices and/or via more advanced means such as the aforementioned API. As an example of the former (merely the notion of doing things in a more global and flexible way), consider the practice by which videos are normally embedded, and how that practice can change over time. For example, we commonly encounter sites with issues involving old-style video embed codes, an area where being able to make global changes very easily to a large web site offers a much more empowering ability to control the site. If you remember back only 4 or 5 years ago, YouTube's embed codes looked quite different. A typical embed code then might have looked like this:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase=" pub/shockwave/cabs /flash/,0,40,0">
<param name="allowFullScreen" value="true">
<param name="allowscriptaccess" value="always">
<param name="src" value=" XXXXXXXXXXX &amp;hl=en&amp;fs=1&amp;rel=0">
<embed type="application/x-shockwave-flash" src=" XXXXXXXXXXX &amp;hl=en&amp;fs=1&amp;rel=0" allowfullscreen="true" allowscriptaccess="always" title="Adobe Flash Player">

Today, that same video’s embed code is handled by iframes, and looks like this:

<iframe width=”640" height=”480"src=” XXXXXXXXXXX ?rel=0" frameborder=”0"allowfullscreen></iframe>

Tomorrow, or in 6 months or a year, that could change again, or you may simply wish to make a global change such as adding a class to the iframe, changing the sizing, adding additional parameters, and/or making accommodations for mobile viewers. But, how would your web site easily keep up or change if it wishes to update that code for hundreds (or more) videos? Manually, that would take quite a long time, and would be tedious work.

In the example above, though, you can see a common denominator in the video ID, which I have shown in both examples as “XXXXXXXXXXX”. Really, with that sole piece of info, the rest can be built around it as needed. In this example, what you’d need is a script that takes your video ID and builds each embed code as desired. In Joomla or Wordpress, that’s something a plugin would do. Typically, you might just enter something in your post’s HTML like:


… and the plugin would intercept that, see that it’s meant as a video embed, and then build the embed code around that, right in your article / posting. Pretty simple stuff, and now you’re able, via the plugin, to make global changes on a web site.

For that, there really wasn’t any API integration *needed*, but it would be an example of a positive step toward scalability. If a site was connected to Youtube’s API, though, you’d likely do much of the same thing when generating the embed codes (so that’s one benefit), but the API integration takes the possibilities much further. So, let’s look at a deeper example (although I’m still going to keep it simple for this article).

A (Simple) Business Application for the Youtube API

Let’s say you’re a law firm and you do a bunch of video marketing on various areas of the law your firm specializes in. Maybe you have some sort of database that feeds your site where you house all of your info on various law specialties. Under, say, “Maritime Law” you have a bunch of text, photos, and citations in this database, and maybe you keep a field for related videos. Storing huge chunks of embed codes would be a lot of work, and a lot of data to manage. But, in this example, each time you upload a Youtube video about Maritime Law, you then add that video’s ID to a list in this field. So, let’s say there are three now: XXXXXXXXXXX, YYYYYYYYYYY, and ZZZZZZZZZZZ.

Now, over on YouTube, you already have all of the necessary additional information about your three videos. Each one has a title, a description, etc. (They may also have comments, tags, various thumbnails, and much more data associated — not to mention a ton of account data for you) In this example, you want to run your Maritime Law article on your web page, but then have a bunch of video embeds at the bottom. Maybe you want a thumbnail, a title, and the description to be on the page, linking out to the videos in pop-up modals. Having to manage all of that data in two places (your site and YouTube) would be a monumental pain for a site with hundreds of videos. (And remember, with the simple embed codes discussed above, even if you do them with a plugin, it’s not going to pull in the video description, tags, etc; it’s just going to bring in the standard video player.)

The solution here is to connect your web site to YouTube — and that’s done via YouTube's API. API means Application Programming Interface, and basically lets one system communicate with another in a standardized, programmatic way. Most larger, well-known, well-developed web-based services have APIs these days, and most work similarly. YouTube's API lives at Google, at

Actually, just getting started is usually the toughest part, as you need to sign up, tell Google which APIs you want/need, establish the appropriate credentials for accessing the YouTube account, etc. Once you’re setup, you’ll get an API key, which is the primary goal of this initial step. Then, you can start having your site interact with the YouTube account. I won’t cover the initial part here, as Google’s console actually does a fairly decent job of that. I just want to show how easy it is do accomplish a basic interaction once you’re ready to start getting data from your YouTube account. (This setup, though, can be accomplished in a few minutes, so it’s not too much work to get done. Mostly, it’s in familiarizing yourself with how it’s all organized.)

Basic API Code Example, Using PHP

Okay, so you’ve got your API key, and now you just want to pull in those three videos on your Maritime Law page. One pretty easy method is via a normal curl request. So, again, let’s say you’re storing that comma-delimited list of vids for each area of the law on your system. Your code might do something like this:

/* Your code will probably go fetch a comma-delimited list from the DB, but for now we'll just pre-populate a variable w/ a sample list... */

// Clean up, if needed... e.g., I included extra spaces above
$storedIDList = str_replace(' ', '', $storedIDList);

// Make into an array...
$IDarray = array();
$IDarray = explode(",", $storedIDList);

// Format as a string for use in the URL...
$numIDs = sizeof ($IDarray);
for ($xx=0; $xx<$numIDs; $xx++) {
if ($xx>0) { $IDstring .= "%2C"; }
$IDstring .= $IDarray[$xx];

// Build out the fetch URL...
$thePart   = "snippet";   // good enough for this example, but see API documentation for options
$theAPIkey  = 'replace-this-with-your-API-key';
$theURL   = "" . $IDstring . "&part=".$thePart."&key=".$theAPIkey;

// Ok, go fetch the data...
// cUrl needs to be working on your server.
$timeout = 5; // set to zero for no timeout  
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $theURL);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
if ( $file_contents === FALSE ) {
echo 'cURL error: ' . curl_error($ch);

From there, $file_contents would be a normal JSON wad. Initially, you would want to dump that out to the screen and take a look at what all comes through via such a request. That will help you understand what’s returned to you by the API. But, as it’s JSON, you can of course continue with your program to iterate through the results and output to your web page whatever you like.

The above is, of course, only one extremely simplified example of how a web site’s possible interaction with the YouTube API (via PHP here, but it can be done in many languages). In this case, it requires no helper classes or anything much at all; just send YouTube a request, get back data, and then use that data to build out your web pages as you like.

Of course, you’d want to build in more error handling, validations, and other features of any decent program, not to mention probably doing things I did above in a way you’d prefer vs. whatever I did. But, that’s the ultra starter-level example that might help you get going. More complex examples include being able to do almost *anything* you can do on YouTube itself, plus some additional functionality not so easily handled on YouTube.

How Do You Know If Integrating YouTube's API with Your Web Site May Prove Beneficial?

This is the important question! Here’s what I recommend as a process to help you decide if your company may benefit from integrating your web site with YouTube via the API, versus just managing things manually. To start, answer these questions:

  • Is video marketing something my company does now?
  • Is our commitment to video marketing fairly strong (meaning we plan to continue with video marketing into the forseeable future)?
  • Is our inventory of videos currently in excess of 100 videos on Youtube?
  • If yes to the top 3 questions: Might we be looking at any kind of web site redesign in the next 6 months to one year?
  • If yes to the top 3 questions: Might we be considering design modifications for enhanced mobile user experiences?

Generally speaking, if you answered yes to just the top two, I’d say keep this on your radar, but it’s not a priority. If you answered yes to the top three, you should be looking at this because the enhanced efficiency realized will allow you or your web administrators to do more in less time, thus allowing you an opportunity to easily scale and benefit from that. If you answered yes to four or more, you should *definitely* be looking at this as soon as possible, and definitely before any redesign or restructuring.

Jim Dee heads up Array Web Development, LLC in Portland, OR. He’s the editor of “Web Designer | Web Developer” magazine and a contributor to many online publications. You can reach him at: Jim [at]