Instagram, the largest photo-only distribution social network, has exploded in usage. With 60 million photos uploaded every day, the app is now cemented as a major social entity.

Third party apps which tied into Instagram were a critical part of originally growing the platform. It seems unfair to these developers then, when Instagram makes unsavory headlines time and time again for increasing API restrictions which cut them out of the picture. For developer clients, the bane of Instagram is it’s closed door attitude when it comes to third party developer innovation. Why is that so?

With Instagram’s harsh policy toward third party clients, it gets one thinking, why have a public API at all? These changes seem to be the antithesis of developer experience. The answer involves a mixture of business and platform security.

This is an all too common scenario in the Public Social API arena, in which service fluctuation seems to be the norm. In this case study, we track the history of the Instagram API to see why the platform evolved as it did, to hopefully shed light on where large Public API programs are headed in the future, and the business make-up behind bold moves toward limitation that continually emerge among public social API programs.

Instagram’s 6 Major User Experience Issues

The simplicity of Instagram is what drove its exponential adoption. But this means its feature set is quite limiting — that’s where third party apps have historically come in to extend the platform out of issues such as:

• Mobile ≠ Web: The mobile experience does not match the web browser experience.
• Hi-res photo upload: Instagram is mobile-first, to a fault. Because of this, uploading high-quality photos (taken from a DSLR camera, for example) requires some very awkward maneuvering.
• Agent-switching: There is no way to easily change users to manage multiple Instagram accounts — a hang-up for brand marketers.
• No shareability: A user can only share photos with other Instagram users — there is no ability within the app to download photos to local or cloud storage, email, or to share to other social networks.
• Incomplete platform support: Instagram was historically mobile-only; they don’t officially support Mac OSX or Windows with native applications.
• Real-time publishing: No scheduling features are allowed, causing social marketers trouble when they want to automate publishing to Instagram using platforms like Buffer or CoSchedule.

Third Party Developer Efforts to Extend the Platform

When Instagram opened their Realtime API in 2011, it seemed developers could finally implement their own solutions to add the functionality that Instagram was unwilling to develop on their own end.

So, naturally, developers created apps that used the Instagram API, and many iterations were spawned. An entire ecosystem of apps was formed tapping into Instagram to create tools like Webstagram, an alternative Instagram picture visualization option coined the “missing web interface”, Instabackup, Instagram download apps, Instagram scheduling tools, and more. However, over time, these services began to fluctuate or even go off line. Instagram has earned a reputation as a strict rule-enforcer of their terms of service (TOS), shutting down third party apps like Followgram, Instarchive, and Rokagram.

Most Recent API Change

In November 2015, Instagram updated their TOS with some pretty drastic restrictions, the implications of which are just beginning to ripple throughout their API ecosystem — the update will deprecate two popular feed endpoints /users/self/feed and /media/popular. These changes will, in turn, will cut off access to any app that wants access to a user’s entire Instagram feed. This move comes after the deprecation of RSS support and the Count API by Twitter in late 2015.

Instagram’s API updates could affect the platform in the following ways:

Good Outcomes

• Helps get rid of fake like and follower programs.
• Cleans up the platform as a whole.
• Increases security by limiting malicious apps like InstaAgent.

Bad Outcomes

• Legitimate apps that extend Instagram to now unsupported platforms will be affected.
• Many good developers pay the price of the actions of a few bad ones.
• End users will lose the functionality of certain apps.

The Reality of Instagram’s “Public” API

Many apps rely on the deprecated Instagram feed APIs, and will likely change drastically in the coming months. Developers hurt, and end users are affected too — it’s an all-too-common scenario in which digital marketers may incorporate an Instagram scheduling app into their work process, only to have it shut down after it’s reliance is solidified into their daily routines.

The reality is that Instagram’s terms of service is too limiting for any remarkable innovation to occur. This closed door reality is apparent from the terms of service, and the stipulations made in the Instagram API documentation, but not so much from the branding of the service as a public API. Rather than sustaining a transparent public API program, Instagram’s profitiabilty will emerge from lucrative partner advertising.

Closer Look at the Instagram Platform Policy & API Documentation

There are three things that developers are allowed to do with the Instagram API:

• Help individuals share their own content with 3rd party apps.
• Help brands and advertisers understand, manage their audience and media rights.
• Help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution.

These stipulations allow one to do around 8 different things with the API. The example calls below, taken from the public Instagram API docs, are mainly concerned with reading and like/comment engagement — note that there is no call for direct publishing:

basic – to read a user’s profile info and media (granted by default)
public_content – to read any public profile info and media on a user’s behalf
follower_list – to read the list of followers and followed-by users
comments – to post and delete comments on a user’s behalf
relationships – to follow and unfollow accounts on a user’s behalf
likes – to like and unlike media on a user’s behalf

The Instagram Platform Policy lays out the following points which are often abused by third party devs that are inevitably shutdown:

“5. Don’t store or cache Instagram login credentials”
“32. Don’t reverse engineer the Instagram APIs or any of Instagram’s apps.”

Turn from Public to Partner: The Business Behind Instagram’s Platform Policies

Instagram has the right to protect its brand, so their 2013 decree to ban third party apps with “gram” , “insta”, or ‘“IG” in their name was understandable, though tedious. Then, in fall 2015, Instagram launched an advertising program and Marketing API to attract large ad agencies and businesses. Instagram’s most recent move to deprecate their feed APIs met a more shocked response from the third party app community — further proof that Instagram is moving away from the Public API model, and toward being a Partner API.

It’s easy to argue that these limitations are doing Instagram, owned by Facebook, a huge amount of good. In our list of 5 reasons behind major public API retirements, we found that protecting a distribution channel to be a high reason for public program collapse, and that certainly appears to be the case in Instagram’s push toward partner advertising.

However, entrepreneur web developers want to create new services that solve a user need. This logical process toward an end goal often means that they will continue to leverage undocumented API endpoints to create new services, and eschew the legalize of platform terms of services (as is the case with many Twitter Count API workarounds recently released).

It is possible to maintain superiority as a top player in the digital world while still allowing developers to create adjunct services — many have capitalized on forming API-first SaaS services. Knowing this, what avenue should Instagram take their API? Before we can answer that, it’s important that we separate the traditional business strategy of a social network from the strategy of providing an API.

The historical goal of nearly any traditional social platform has been to make money via ads or sponsored content — that is why Instagram is so ambivalent to change, and requires all action to happen, all pictures to be uploaded, viewed, etc. within their own domain. Their mobile ad partner program is huge, including major ad agency partners that access their Partner program which includes a marketing API.

The fact is that Instagram’s public API strategy is interfering with its platform strategy.

Public API-First Monetization

Public APIs don’t have to be free or open source — there are many profitable monetization models out there for Public APIs. For an API provider at an API-first company, your main source of income comes from charging API access to your developer community. You let them figure out how to generate revenue, and they pay you.

If Instagram were to keep it’s Public API, the developer program could offer a tiered data access plan — a freemium/premium model that allows for additional rate calling and functionality paid by the month or per API call. This would:

• Allow developers to create applications that upload to Instagram, help schedule, download pictures, and more.
• Allow Instagram to maintain its business by converting some of its ad revenue to its API usage.
• Extending the social network’s usage into many more applications, increasing traffic, in turn increasing data collection, which could also then be monetized.
• Decrease ads on the Instagram platform, to the betterment of end users and humanity.

The unfortunate reality for third party startups is that Partner API programs have a higher propensity to profit, as in Instagram’s case, they tap into the advertising budgets for large corporations.

Ethical vs Business Response to a Transient Public API

In the future, we will have to reach some sort of conclusion — Is it ethical for a digital company to use a Public API program to grow their clout and user base, only to later on shut out apps with strict API limitations once the parent company hits a critical mass?

“Some of these restrictions sound reasonable, but I worry about some apps finding them too constraining. Already, my favorite Instagram app, InstantSave, has fallen out of the App Store, after I had only been using it for a few months. I’m still smarting over the fact that the world’s handiest app, AppZilla, was pulled from the App Store never to return. All this confirms what I already knew: in the ever-transient online world, it doesn’t pay to become too dependent on any app or any website.” – User Comment on Macworld

Ironically, social APIs from Facebook and Twitter were some of the first adopted and widespread APIs. Now, it seems, a limitation has been reached as open transparency becomes a barrier to profitability. But once an API is out there, it is used, and depended on by many.

Rather than jump straight to releasing a Public API, it is best to open access gradually to avoid eventual deprecations that bring about negative publicity. To make public APIs viable, this means critically thinking about your business decision in each release, not the current industry fad. To us at Nordic APIs, becoming a master of API strategy means deciding whether your API will be private, partner, or public, and testing provisioning access in that order.

What do these large-scale API deprecations mean for the API economy? Some apps entirely rely on social APIs to exist — Hootsuite, Buffer, SproutSocial, etc. The hectic tides of public APIs may cause alarm for newcomers. As a consolation, these major fluctuations mainly occur in the social sphere. The great proof is that hundreds of API-at-their-core companies have emerged that privilege the developer experience and use smart strategy along with releases — the public API model is sustainable in arenas like B2B, health care, analytics, machine learning, open government, and more.

Conclusion

Providing a public API can be problematic in the social setting, where advertising and partner integrations drive business. Any platform with unsolicited API usage needs to seriously consider access management and identity control platform-wide. Ensuring better security measures doesn’t mean giving up on a Public API — in fact, any SaaS model hinges on this sort of identity control to offer tiered subscriptions, in which certain API consumers have certain privileges and some do not.

User data should be protected, and leakages avoided at all times — this sort of quality assurance should involve white hackers vigilantly checking for vulnerabilities. With a high scale of legality vetting, though, Instagram requires even more resources to maintain their strict terms of services. With all the resources dedicated to hampering developers and shutting down apps, it makes one wonder if these resources could instead be repositioned to evangelize new developer growth, to increase both revenue and user growth in new directions.

Though there is certainly business-driven reasoning behind social platform movement toward isolation, consistently hampering 3rd party developer innovation — with an API that appears to be “public” — will not be sustainable in the increasingly API-driven and open source digital world. The Internet should be encouraging innovation whenever possible, not hampering it.

The main lesson? Tread a public API release carefully with the longevity of your platform as a whole in mind from the get go.