An approach for working with legacy API and new API

Introduction

When we first start working with a third-party API, the version we started with may become obsolete after a few years since the legacy API may no longer be supported by the original creators or contains security problems when we need to migrate to newer versions. There could be a variety of other reasons to upgrade, such as the expense of maintaining the legacy API being greater and inefficient than the latest version, as well as support for new features or support from the original providers. In this article, we will be working on Instagram Private API (legacy API) and Instagram Graph API (new API). The Instagram Graph API, which is a set of Facebook Graph API endpoints that let developers access information from Instagram Professional accounts introduced in January 2021. Before it, one of our team at Craftsmen used to use the Instagram Private API to publish social media content on Instagram. So, before we start, let’s call Instagram Graph API as IG-API and Instagram Private API as IP-API for this entire blog, and let’s first explain why we were encouraged to switch from IP-API to IG-API and address an approach for working with both of them.

Reasons for switching to new API

A few months after the first initial release of IG-API, we had cases where our client’s Instagram account got temporarily blocked or suspended while using our services. We investigated what might be the prior reason behind it and got multiple open issues in the IP-API GitHub repository. From our research, we came to the conclusion that IP-API seems to work in that it tries to create a device instance and makes Instagram think that the request is coming from an actual physical device.  But, if we keep doing it on every post publish, and try to use any kind of web service like AWS Lambda to handle the task. Instagram might get suspicious about the incoming requests as we have no control over the IP of the AWS Lambda which it is triggering from. Think of it in this manner, you might get blocked if you keep changing your IP address using VPN and keep posting images from different regions with different IP addresses, you might get locked out or suspended for security reasons.

Our workflow for both legacy and new API

We started developing support for IG-API but unfortunately, of all the features which were offered by IP-API only two were offered by the IG-API. So, we have to make the systems work aside from each other in the following manner. 

While implementing the IG-API, we came across a unique problem, as the new IG-API does not directly support fetching post information that IP-API made.

So how did we fix this problem?

Let’s start small, first, whenever we publish a post on Instagram using IG-API we get a post id for the post which is later used to fetch information about the post using the graph endpoints. Now, though a similar post id is also expected from the IP-API as well unfortunately it sends us a combination of post ig_id and account ig_id connected with an underscore and no post id exists in the IP-API response which is needed to fetch post information with IG-API.

We can fetch a user’s list of media post id with ig_id with IG-API for a specific time range which enables us to narrow down the response. As we keep the logs for each lambda execution’s start and end time for every successful post, we have used it to fetch the list of media post id and ig_id to later find the exact match for the IP-API created post. 

Problem solved, yay!!

But what if we were not that much lucky? The above solution was possible as we had the necessary information at our disposal but what if we did not have any time logs or IG-API does not support the time-based pagination?

An alternative approach

So for the not-lucky case, one might suggest, why not do a system-wide database migration with the new IG-API post id. This might be a good idea, but we had to think of our use cases and costs. As we use AWS Dynamodb for our database, scanning and updating the whole database for post information of Instagram Provider seems overkill to solve the problem. Not to mention, it’s expensive and the client does not have any use cases where they regularly need to see the old post information. So, on another approach, we can fetch all the post id with ig_id using IG-API then make a cross-reference using the IP_API post id’s post ig_id and finally migrate the existing database with the new id and send a response.

But the latency of the above-mentioned process is going to be high as we are fetching all the post id and ig_id for each request which is redundant and chances are our AWS lambda might get timed out if the number of posts is too high. Let’s modify the solution a little bit more, we can introduce cache storage that saves the post id and ig_id while the registration and later find the exact id from there.

The cache storage does not need to be synchronized with the updated post ids as the IP-API is now no longer supported. If it is still to be supported then a scheduler needs to be executed at a certain time interval to fetch and store the updated post ids of IG-API.

Hope you have enjoyed reading this article. Thank you for your time.