Skip to content
This repository

Media resources

Single media (recurring pattern):

{
  "pk": 6844295,
  "media_type": 1,
  "filter_type": "1",
  "device_timestamp": 1291067716.0,
  "user": <user>,
  "taken_at": 1291067762.0,
  "code": "aG-H",
  "likers": [<users>],
  "liker_ids": [<user IDs>],
  "comments": [
    {
      "created_at": 1291067788.0,
      "content_type": "comment",
      "media_id": 6844295,
      "text": "Nisshin City",
      "type": 1,
      "user": <user>
    },
    ...
  ],
  "image_versions": [
    {
      "url": "http://distillery.s3.amazonaws.com/media/-.jpg",
      "type": 5,
      "height": 150,
      "width": 150
    },
    {
      "url": "http://distillery.s3.amazonaws.com/media/-.jpg",
      "type": 6,
      "height": 306,
      "width": 306
    },
    {
      "url": "http://distillery.s3.amazonaws.com/media/-.jpg",
      "type": 7,
      "height": 612,
      "width": 612
    }
  ],
  "lat": 41.39691,
  "lng": 2.170623,
  "location": {
    "external_source": "foursquare",
    "pk": 79981,
    "name": "Teambox HQ",
    "address": "Carrer de Bonsoms, 21",
    "external_id": 1558689,
    "lat": 41.3733147,
    "lng": 2.1263734
  }
}

If the item is not geolocated, location properties ("lat", "lng" and "location") are not present.

Note about "likers" and "liker_ids": sometimes one field is present, sometimes the other. If there aren't many likes, then "likers" field is present and contains user info for each person. Otherwise, "liker_ids" contains only user IDs to save bandwidth for popular items.

Get permalink

GET http://instagr.am/api/v1/media/<ID>/permalink/

{
  "permalink": "http://instagr.am/p/R2FE/",
  "status": "ok"
}

It might seem that this method is unnecessary, since all it does is returns a URL of predictable format containing the media's "code" value ("R2FE" in last example). However, in my testing I found out that permalinks are not active (i.e. will not show the image on the public website) before this resource is hit for the first time. This might be part of their privacy measure to prevent guessing URLs for items which the original author didn't intend to share.

Get embed info

GET http://instagr.am/api/v1/oembed/

Params:

  • url: (required) a permalink in form "http://instagr.am/p/..../"
  • maxwidth: don't link to images larger than this dimension
  • callback: name of callback function for JSONP

Example response:

{
  "title": "Ahead",
  "url": "http://distillery.s3.amazonaws.com/media/-.jpg",
  "height": 306,
  "width": 306,
  "author_name": "stop",
  "author_url": "http://instagr.am/",
  "provider_url": "http://instagr.am/",
  "provider_name": "Instagram",
  "version": "1.0",
  "type": "photo"
}

Like item

GET http://instagr.am/api/v1/media/<ID>/like/

{"status": "ok"}

Unlike item

GET http://instagr.am/api/v1/media/<ID>/unlike/

{"status": "ok"}

Delete item

GET http://instagr.am/api/v1/media/908966/delete/

{"status": "ok"}

Post comment

POST http://instagr.am/api/v1/media/<ID>/comment/

Params:

  • comment_text: comment body

Example response:

{
  "comment": {
    "created_at": 1291073754.0,
    "content_type": "comment",
    "media_id": 6755764,
    "text": "...",
    "type": 0,
    "user_id": 35241,
    "user": <user>
  },
  "status": "ok"
}

Post new media

Posting appears to happen in two phases:

POST http://instagr.am/api/v1/media/upload/

Params (multipart post):

  • device_timestamp: timestamp (in seconds)
  • lat: latitude
  • lng: longitude
  • photo: file

Response is the usual {"status": "ok"}.

New media: second phase

POST https://instagr.am/api/v1/media/configure/

(Not sure why the second one is over HTTPS.)

Params:

  • device_timestamp: timestamp (in seconds)
  • caption: will appear as first comment
  • filter_type: filter code
  • source_type: source code

    { "media": , "status": "ok" }

Something went wrong with that request. Please try again.