Instagram Developers @instagram-developers - Tumblr Blog

Instagram Platform Update Effective June 1, 2016

Last year we announced that Instagram would be making updates to our Platform Policy to improve people’s control over their content and set up a more sustainable environment built around authentic experiences on the Instagram Platform. These changes included a more focused set of terms, a new permissions review process, and the deprecation of the /users/self/feed and /media/popular API endpoints.

These changes were implemented back in November for new apps. We've been in contact with existing apps via email, and they've been given until today, June 1, 2016, to apply and get approved. Apps that have not been approved will be sandboxed. Most apps will be reviewed within a week of submission.

We've reviewed and approved thousands of submissions, and are excited by all the great ways developers have enabled the Instagram community to share their own content. We've also seen innovative business solutions, including those from the Instagram Partner Program, which has grown to more than 50 businesses and added media buyers. Developers that help broadcasters and publishers discover and get rights to content have also continued to evolve, and embeds continue to be a top source for visual content, creating billions of impressions each month.

As a reminder, approved apps fall into the following approved use cases:

Apps that help individuals share their own content with 3rd party apps.

Apps that help brands and advertisers understand and manage their audience and media rights.

Apps that help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution.

If your app was not approved and you still wish to use Instagram APIs, please review our accepted use cases and policies here.

Thanks to everyone who applied for review. We realize that these updates require changes from many of you. We hope that these policies will provide a clearer roadmap for developers and continue to keep the community in control of their content.

Location API update

Starting April 20th, 2016, the /location/search endpoint will stop supporting the foursquare_id and foursquare_v2_id parameters. The endpoint will continue to support search by lat, lng and by facebook_places_id.

Instagram Platform Update

Reminder: Instagram's platform changes will go into effect for apps created before November 17, 2015 on Wednesday, June 1, 2016. If you have not yet applied for permissions review, please do so here. Apps that have not been approved and were created before November 17, 2015 will go into sandbox mode on June 1, 2016.

---

When we launched our first Instagram API in 2011, we were a very small team and knew we wouldn't be able to build all the features our community might want. Today we are announcing several platform changes to improve people's control over their content and set up a more sustainable environment built around authentic experiences on the platform.

Simplified platform policy

We've updated our Platform Policy to explicitly list the use cases we will support moving forward. These include apps and services that:

Help individuals share their own content with 3rd party apps, such as apps that let you print your photos and import an Instagram photo as a profile picture.

Help brands and advertisers understand and manage their audience, develop their content strategy, and get digital rights to media. Established apps in this space may apply for our newly announced Instagram Partner Program.

Help broadcasters and publishers discover content, get digital rights to media, and share media using web embeds.

You can read the full terms here.

New review process and sandbox

We will begin reviewing new and existing apps before granting full API access starting December 3, 2015. Existing apps have until June 1, 2016 to submit and be approved.

We are also launching Sandbox Mode, which will let you privately build and test your apps using Instagram's APIs as your app is being reviewed.

More control for the community

We've heard from the community that it can be unclear where their content is being shared and viewed, so today we are deprecating the /users/self/feed and /media/popular API endpoints for new apps. Existing apps will have until the end of the review period before access to the endpoints is terminated.

Our goal is to provide a focused set of terms and processes that give clarity to the use cases we will support going forward. While this may require changes from many of you, we believe these changes will help maintain control for the community and provide a clear roadmap for developers.

To learn more and begin the permissions review process, visit https://instagram.com/developer/.

API migration for landscape and portrait formats

As announced in the blog post, in addition to square posts, people can now share photos and videos in both portrait and landscape orientation on Instagram. Today, we are introducing the support for this new format via the Instagram API. This means that all endpoints that return images or videos can now provide URLs of non-square media. We understand that this affects developers that may need time to update their integrations, so we are giving you control to decide when to start receiving media in the new format. This is done by enabling a new setting called Migrations in the "Edit Client" dashboard. By default, the setting is disabled and the API will continue to return media in the old square format. When enabled, the API will return media in the format it was actually shared, which may be non-square. The 'thumbnail' images will not be affected by this setting, and they will continue to be square. Note that this migration setting will be available until June 1, 2016. On this date, all clients will receive photos and videos only in the format it was actually shared.

Embedding endpoints

These endpoints are not affected by the migration setting and they will continue to return media in the format it was shared.

Removing pre-filled captions from mobile sharing

Instagram has a vibrant creative community, and third party apps that allow users to create images and share them through the Instagram native apps can offer people additional opportunities for creative expression. However, we've gotten feedback that the pre-filled captions coming through this sharing channel often feel spammy. In an effort to protect our community and keep interactions on Instagram authentic, we are removing pre-filled captions from mobile sharing. Beginning today, the iOS Hooks and Android Intents will stop accepting captions passed by third party apps. This is a non-breaking change: existing mobile apps that utilize pre-filled captions will continue to be able to use this flow to share media through the Instagram apps, but now Instagram will ignore the caption text. To create a caption for a photo or video shared by a third party app, users will have to enter a caption manually, the same way they already do when sharing content using the Instagram native apps. We hope this change will continue to foster high-quality, authentic sharing on Instagram.

Publishing guidelines and signed requests

Over 300 million Instagrammers use the app every month to capture and share the world’s moments with friends and the broader community. This growing audience, and the beautiful photos and videos they post every day, have driven increased interest from developers to build creative and innovative apps using the Instagram API. Today, we are making updates to our API to ensure positive and authentic experiences for our community, as well as provide developers with better tools to protect their products.

Guidelines for Publishing Likes and Relationships Actions

New Apps

Starting today, any newly created client_id that wishes to issue POST and DELETE requests to the Likes or Relationships API endpoints will first have to request that access. This will follow the same process that we introduced for posting comments last year. Examples of use-cases that will be considered for access include:

Media rights management: for example a platform for media publishers and brands to request permission from the Instagram community to use Instagram content.

Social media management: for example, a platform to help businesses integrate Instagram in their social media workflow.

Developers who feel they have met the requirements and meet API terms can request access here.

Existing Apps

For already existing applications that are using the POST endpoints, we will continue to ensure that they comply with our terms and approved scenarios. However, if an app has not posted a Like/Follow since January 1, 2015, that app will have until April 28, 2015 to make a formal request for access before access is turned off.

Enhanced Security When Signing API Requests

We are also providing an enhanced way for developers to sign their API requests. The new 'Enforce signed request' option instructs Instagram to verify each API call for a valid HMAC (Hash Message Authentication Code). This code is produced by signing the API call parameters with a secret key that is only shared with Instagram and the developer.

This technique helps mitigate impersonation attempts and protects developers from targeted abuses by malicious actors. Additionally, those developers signing their requests will enjoy higher rate-limits for various endpoints. Please read the documentation for more information.

Previous Signing Method Deprecation

For developers who have already been signing API requests, thank you for ensuring the quality of your API calls. We ask that you make the incremental change to use the enhanced method by September 1, 2015.

Thank you for helping us keep the Platform safe and fun for the Instagram community.

API bug fixes

Thanks to all developers who reported issues through the bug tool: http://instagram.com/developer/support/

There has been a long standing bug where some endpoints containing the 'user' node would have empty 'bio' and 'website' fields. We have now removed those fields from all endpoints except /users/<user-id> and /users/self. The sample responses in the docs have also been updated to reflect the change.

Update to Embedded posts and oEmbed endpoint

We are excited to introduce a beautiful update for the Instagram Embedded posts that is mobile friendly, has a Follow button, shows the caption, and supports HTTPS.

Every day, Instagram embedded posts are seen by millions of people on websites around the world. Publishers and content producers use embedded posts to present beautiful content from the community, illustrate how current events are unfolding, or simply show a news worthy moment. The new embedded post is redesigned from the ground up and introduces a set of features that have been highly requested both from our community and from publishers:

Fully resizable. Embedded posts look great on mobile, are resizable and responsive. This makes it so much easier for publishers to put it on their sites.

Follow button. Embedded posts show a convenient Follow button. On mobile, it links directly to the Instagram app so you can see more of the account that is being featured. If you don’t have the app installed or you are not logged into Instagram on your mobile browser, the Follow button is replaced by a Get Instagram button so you can easily get the app.

Caption. Now embedded posts provide the option to include the post caption, which helps tell a better story.

HTTPS support. Embedded posts support HTTPS, which means that secure websites can also use it.

For developers, we are updating the oEmbed endpoint to make it easier to integrate the Instagram embedded posts in websites and publishing platforms. The oEmbed standard defines three ways to describe a URL: 'photo', 'video', and 'rich' (check out www.oembed.com for more information on the oEmbed format and types). Until now the Instagram oEmbed endpoint returned the photo and video types.

Going forward the endpoint will use type 'rich' and return the same html embed code that you can get from the Embed button on instagram.com pages. This will make it easier for applications to programmatically render embedded posts. This new behavior for the oEmbed endpoint will be live on November 3rd, 2014. To get your application ready, you can already test the new response by passing the parameter beta=true. For example:

https://api.instagram.com/oembed/?url=http://instagram.com/p/bNd86MSFv6/&beta=true

You can find the new documentation for the oEmbed endpoint on the developer site: instagram.com/developer/embedding/

Changelog

Parameters

hidecaption: The endpoint supports a new parameter called 'hide_caption' with default value 'false'. If set to 'true', the embed code won't show the caption.

maxheight: The endpoint does not support the 'maxheight' parameter. This is because the embed with caption has variable height depending on length of text and width. The height can also change since the embed code is now responsive. Old embeds using the iframe code will still work as they are today.

maxwidth: If specified, the maxwidth parameter must be greater or equal to 320. Requesting a smaller value causes a HTTP 400 error.

JSON response

type: the type returned is always “rich”, both for photos and videos.

html: this is required for type rich and contains the embed code.

height: this is always null.

width: the default value is 656, but the embed is responsive so the width actually adapts to the container.

thumbnail_url, thumbnail_width, thumbnail_height: if present, the thumbnail data gives an image representation of the embed. If there is no available thumbnail for the embed, these fields are not returned.

Guidelines for Comments API POST endpoint now in effect

Last month, we announced a new set of guidelines that we will begin to apply to all comments posted through the Comments POST endpoint. These guidelines are now in effect.

You can find more information on these guidelines on our developer site at: http://instagram.com/developer/endpoints/comments/

New rate limits in effect

Last month, we announced some new tools to help us better identify the API calls that your app makes to Instagram. Along with these tools, we introduced a new method for rate-limiting POSTs made to our platform which are now in effect. You can find more information on these new rate limits on our developer site at: http://instagram.com/developer/limits/

API bug fixes

Thanks to all developers who reported issues through the bug tool: http://instagram.com/developer/support/ This is the list of recent fixes to the Instagram API: - Fix /oembed endpoint to return correct images when using maxheight or maxwidth parameters. - Fix /tags/{tagname}/media/recent endpoint to return correct pagination parameters max_tag_id and min_tag_id.

New guidelines for Comments API POST endpoint

With explicit permission from an Instagram user, approved developers have the ability to post comments on that user's behalf through the Comments POST endpoint and we're committed to ensuring that developers using this endpoint are creating high quality experiences for our community. To that end, we're going to begin to require that all comments posted through this endpoint meet the following guidelines, starting on July 19, 2014.

The total length of the comment cannot exceed 300 characters

The comment cannot contain more than 4 hashtags

The comment cannot contain more than 1 URL

The comment cannot consist of all capital letters

If a comment posted through the API does not meet one of these conditions, an error response will be returned and the comment will not be posted. A specific reason will be returned to help you resolve the issue before any re-attempts. For example:

{"code": 400, "error_type": "APICommentTooLongError", "error_message": "Your comment is too long."}

In order to provide a good experience to people that use your service, we recommend that you provide meaningful messages so that people understand why their comment was not successfully posted in these cases. For more information on these guidelines and the expected error responses, please refer to our Developer Site.

New tools and rate limits for POST endpoints

Today we're announcing new tools to help us better identify the API calls that your app makes to Instagram. These new tools will bring more consistency and stability to your app since our systems will now have a stronger understanding of the calls that you make, enabling us to help support you in the best way possible. As part of these new tools, we are also introducing a new method for rate-limiting POSTs made to our platform which will go into effect on July 7, 2014. Disable Client-Side (Implicit) Authentication For apps that issue API calls to Instagram server-side, we have introduced a new setting to your OAuth Client configuration which will cause all Client-Side (Implicit) authorizations requests to be rejected. Given the convenience of the Implicit OAuth Grant flow, we've found many developers opting for this approach, even though it was only created to support javascript and mobile clients. Server-side apps should take advantage of this new setting in order to prevent malicious developers from impersonating your OAuth Client through the implicit flow and capturing access tokens from unsuspecting people. Enforce Signed Header In order to help us better verify the identity of your app as the source of API calls being made on behalf of your OAuth Client, we have also added support for a new HTTP header which signs your API requests. By enabling the new Enforce signed header setting on your OAuth Client configuration, we will verify the signature in the X-Insta-Forwarded-For HTTP header and reject any API calls that do not match. As with disabling client-side authentication, we encourage all developers with server-side apps to begin securing their API calls with this HTTP header. Revised Rate Limits on POSTs On July 7, 2014, we will introduce a new method for rate-limiting POSTs made to the Instagram Platform in which a different set of rate limits will be applied based on whether your app is issuing signed requests or not. Under this new model, we will provide an elevated set of rate limits for apps that secure their OAuth Clients by performing the two following actions:

Disabling Client-Side (Implicit) Authentication

Signing all POSTs and DELETEs to Instagram Platform with the X-Insta-Forwarded-For HTTP header

The following new rate limits will go into effect on July 7, 2014:

Unsigned Calls (per OAuth token):

POST /media/media-id/likes: 30/hour

POST /media/media-id/comments: 15/hour

POST /users/user-id/relationships: 20/hour

Signed Calls (per OAuth token):

POST /media/media-id/likes: 100/hour

POST /media/media-id/comments: 60/hour

POST /users/user-id/relationships: 60/hour

Support for HTTP 429 Status Code In order to provide more clarity when a rate limit condition has been hit, we will begin returning the HTTP status code 429 (Too Many Requests) for calls that exceed the rate limit for a particular endpoint. The following changes take effect today:

Requests with user tokens that exceed a rate limit will now return HTTP status code 429 (previously 400)

Requests that exceed the global rate limit for a client ID will return HTTP status code 429 (previously 420)

Updated Libraries Lastly, we have updated our Python and Ruby libraries to add support for the new X-Insta-Forwarded-For HTTP header as well as the new HTTP 429 status code. These updated libraries can be found on our developer site.

Instagram Python SDK v1

Following on from the Ruby SDK v1 release, we’re happy to announce the Python Instagram SDK v1 release. Once again, a big thanks goes to all the contributors from the Github community. We look forward to seeing more great applications built on the Instagram Platform.

Release notes:

Video Support

Easy Accces to Rate Limit Information

Easier Pagination

Improved Sample Application

More Expressive Error Messages, e.g OAuthRateLimitExceeded

Instagram Ruby SDK v1

Yesterday we released v1.0.0 of the Ruby SDK. This would not have been possible without significant contributions from the Instagram Github community. Thank you!

Release Notes:

New Sample App – updated with greater endpoint coverage

Improved Readme and documentation

Now Supports Faraday 0.9 – making the gem much more compatible with other popular gem’s

Better pagination support

Improved realtime/subscriptions support

Easy access to rate limit data

Various smalls improvements and bug fixes

API returning 500 errors on specific IP

We have received reports that certain servers are consistently getting 500 errors when hitting any endpoint. We are looking into this issue and working to get it fixed as soon as possible.

#API health

API services have been restored

Apologies for any inconveniences you may have encountered

#API health

Trending Blogs

Recently Viewed Blogs

Instagram Developers