Instagram Integration

September 23, 2020

Not that long ago I decided to completely rework the way my website was laid out. I hope to do a blog post dedicated to some of that but when it came to the home page I knew only that I wanted it to have ways to get to my most recent content. These projects usually have some nice images associated with them, but I also wanted to add a feed from my new Instagram account. There are many companies out there that sell the service. Basically you tell them what you want to display and they give you a code snippet that you drop in the code for your page. Some of them are very nice, with many ways to customize the code, but most of them want you to pay something for the service. Since I am not making money from this site, I really didn't want to pay a company just to display images that I own anyway. I decided to poke around the web and see what I could find. That's when I came across the Instagram Graph API. 

API stands for application programming interface and the definition can sometimes leave you more confused than you were before you read it. The short explanation is that it is a common way for two pieces of software to exchange information. Much of this started with the idea of Web 2.0, the buzzword of all buzzwords a number of years ago. Basically there are publishers, like Instagram, who have data to be consumed. In my case, this is the link, caption, and image URLs from my posts. Other publishers provide information like the weather, news headlines, or stock data. The API provides a set of rules and methods for requesting the information. For instance, getting the weather may need you to send the desired zip code to http://sampleweather.com/forecast. That may provide today's forecast, but if you want the 5-day forecast you may have to send your zip code to http://sampleweather.com/5day. The API documentation tells users where to get the data and what they can expect in response. 

This journey really has two parts. When I first redesigned my site I was able to set up an app, get myself authenticated, and download my data. I believe that it was working for a couple of months. Recently, I went to my homepage and noticed that the Instagram feed was broken so I logged in and it seems that while I was not paying attention Instagram updated their API and since I was not using the new API, my app was deemed inactive and disabled. I will say, simply, that is very frustrating when something like this happens. So last night I decided to see if I could figure out what was wrong and try to get it up and running again. 

What I am going to provide is an overview of my process, which is not a step-by-step walkthrough. For a good getting started guide, check out the documentation linked below.

Facebook bought Instagram for $1 billion, yes, with a "b" in 2012. In recent years Facebook has started trying to move the two platforms closer together. Logging in to my Facebook for developers account, I checked that my app still had the Instagram products added. Since the last time I had the app working my IDs had been changed, the URLs had been changed, and the permissions had been updated as well. The steps are described well in the documentation.

Your initial request tells Instagram what app is requesting permission, what you want to access, and where it should send the information once it has been approved. In my case, I load my test page and click a link that takes me to Instagram where I am asked to approve that the application can access my information. Once the application is authorized it redirects the user to the specified page with an authorization code tacked on to the URL. Your landing page now has to exchange that authorization code for a user access token. Your second request includes the application ID, an application secret (kind of like a password), and the authorization code. This time, you will get back a user id and an access token. To display the feed I will need to be able to use the access token multiple times so I stored the access token somewhere safe under the key of my user id. I admit that I had some trouble in the next part, though I blame some of it on the documentation and some on the change from the previous methods. 

I thought that once I had the access token I was all set. Then, after an hour or two, my feed started getting messages about the token expiring. It turns out that the basic token you get is only meant to be a short-lived token. To get a token that is good for up to 60 days, you have to exchange the short-lived token for a longer-lived one. It's all right there in the documentation if you know what to look for. The long-lived token can even be refreshed for a new one when the expiration gets close. I wrote a script that runs daily that checks if the token expiration is close and then tries to renew it. As I said, the token should be good for 60 days, but each time you request a long-lived token you get back a number which indicates how many seconds until the token expires. Although it won't complain if you try to renew a token right away, it also won't change the expiration time so I do not believe it issues a new token until the expiration date approaches. 

That was the final piece to the puzzle, but what really had me stumped for a bit last night was how to request information. Under the previous API a simple call got me all the information from my latest posts. So when my first request returned a bunch of ID numbers I was pretty discouraged, thinking that I would need to load the IDs, then request the information for each post separately. Fortunately, I was able to find some documentation that suggested sending a list of fields that I wanted would add those to the response and it worked! In the case of carousels (or image gallery) style posts, including children will get you the IDs of the children posts, but adding children.{field name} will get you additional fields. This lowered the feared explosion of API calls to only one call. 

Once the data is received the process of breaking it down is very straightforward. Stepping through each post there is the ability to see the time the post was made, caption, username, type of post, URL of the image (or video), and, in the case of carousels, information about the children. I chose to do a typical 4 across display, with an animated change for when there's more than one image. While I was redoing the display I was able to work out displaying an inline HTML5 video so now images and videos can be displayed side-by-side. Really, at this point, it's all up to what the developer wants to do with the data. I have considered having a page that displays more posts, but that's what Instagram is for, so maybe I will just leave that to the professionals. 

Usually, I end projects with lessons I've learned, or things that I would do better but I feel like that's most of what this post was about. I am glad to have my display working again, and I don't mind learning, but I wish that there were a better way to transition users from an old API to a new one. I also found that in the changeover Instagram no longer shares the count of likes for general users, only for business accounts. While I don't feel a strong need to drive up the number of likes, I do like to see it and don't mind sharing, so I was disappointed to see that go away. Anyway, if you made it this far, thanks for reading, and if you try this yourself I wish you an easier time than I had! 

Categories: PHP  Instagram  API  Programming