Here at Socialtyze, we interface with tons of social media platforms, including Facebook, Instagram, Twitter, and Vine, just to name a few. So you can imagine an API that’s designed with the consumer in mind means a lot to us. It allows us to focus more on the creation of our own apps, rather than fussing with irritating queries, rate limits and user tokens. With that in mind, I’d like to single out a few features on a couple of APIs that make a developer’s life easier (or harder).

1. Instagram rate limits included in the headers

If you’re like us, you make hundreds or thousands of calls to Instagram’s API every hour. This makes rate limits a real factor in the way we design our back end apps. This makes knowing - and keeping track of - how many remaining calls you have a critical piece of information. The last thing you want to happen is to have your account throttled by the Instagram servers and completely shut down your app.

Thankfully, Instagram actually returns that information with each call you make to the API:

Since you get both the total number of calls remaining and the total you started with, you can regulate your queries based on how many calls you have.

Instagram isn’t without its faults though. Good luck trying to get the comment and like data for media through their API. Each endpoint is capped at around 150 entries - and no pagination! So if you want to see the entire list of users who liked your photo - you’re out of luck!

2. Twitter’s real-time streaming endpoint

Twitter’s RESTful Search API is great, but as we all know - it’s built for relevancy and not completeness. Since not every tweet is indexed to search, you only get results within a certain time period and even then, relevancy is key. This is where the Twitter Streaming API comes in. We’re able to listen to hundreds of different hashtags in real-time, funneling them into a global tweet database for our clients to access. This is great because we get to examine the data on our own terms without having to deal with pesky rate limits. One downfall of the Twitter Streaming API is that it only provides you up to 1% of the total volume of tweets on the service. This means that if you’re listening to a hashtag that has significant activity - you’re going to lose some tweets. This is where the RESTful Search API comes in again. We’ll use this service to perform a daily backfill of tweets we may have missed. Using these two APIs in parallel allows us to be confident that we’ve caught every tweet we can.

3. Google Analytics API

For many internal analytics dashboards, we turn to Google Analytics to provide the data on our apps. It’s convenient for developers, and it’s reassuring to clients because they’re already familiar with the metrics that Google Analytics provides. That being said, Google makes it a bit of a chore to authenticate your server application with their API. On top of the normal Client ID, you’ll need to pull down a json file along with a P12 cryptographic key to make calls to the Google service API. This type of authentication may seem excessive, but this method is used to authenticate with every single API on Google’s servers. This means you can access BigQuery, the Prediction, or Google Drive APIs all through the same app, if they’re enabled.

4. Facebook’s Pagination

Facebook’s API has gone through numerous iterations over its lifetime. Facebook’s pagination design is great when it works - and extremely frustrating when it doesn’t. Facebook chose to go with a couple different methods of pagination depending on which API endpoint you’re calling. It could be cursor based, time based or offset based. This can be hard to work with at first because often times Facebook will not tell you which pagination scheme works with each endpoint.

As an aside, one of the great things about Facebook is that you can file a bug directly with Facebook through their website. Is the endpoint you’re working with giving you trouble? Open a ticket and let them know!

5. Vine’s Tag API

Vine’s API is a great, simple API. There are a few endpoints that you can access, and you don’t have to mess around with any app tokens (yet). The pagination is ‘page’ based, meaning that you are given a set amount of vines per page, and can move through the pages by page number (eg. 1,2,3,4, etc). You typically see this type of pagination when building an app that allows the user to paginate through results instead of the server. For instance, if an app were displaying a list of top vine videos, there would be a ‘next’ button for the user to click.

That’s great for user facing apps, but for developing server side applications, we’ve run into a couple of issues. For starters, there is no way to return results based on where you left off from a previous query. You can’t query based on date, and you can’t retrieve newer results from the last time you queried. This may have a lot to do with Vine seemingly being hesitant to bring the API from out of the shadows and into the public eye. As it currently stands, Vine’s API isn’t officially documented. Hopefully we’ll see more consumer focused API design in the future as Vine decides to make their API more public.

Want more tips and tricks for how to dominate social this year with Data, Creative and Amplification? Download our 2016 Social Media Survival Guide.