I have real time subscription for really popular tag.
My app gets many subscription calls in second and then i am making post request to tag/media/recent, but i am getting duplicate and skipped images because it is very fast. How can i get sure that i request for image that subscription call is sent?
I tried even to set count to 1, and store last min_tag_id, but i am getting duplicates and missed images also.
my idea was to get last picture id, then on subscription call to set sleep for sometime and then call tag/media/recent with count=1 and min_tag_id and i will get picture for that subscription call, but there are still duplicates.
Why Instagram is not simply sending picture ids?
I have been having the same issue as you (working on this over the last week). My workaround, currently, is after Instagram sends a POST that an update for the hashtag has happened, I do a POST call for the most recent photos (currently setting count to 1 as you're doing but still working on getting all the newest photos).
I basically store all the latest photos returned in a database using the photos id as the primary key. If the key already exists in the db I issue an update otherwise the new photo gets inserted into the database. I then check whether an update was called or an insert was called. If an update, I simply exit the function. If an insert was called, I then issue a response to the browser with the new photo (this is very easy to do with web sockets; alternatively you can simply poll your database over a set interval to check if new photos were added).
I'm not even sure if this is a correct approach, it feels very hacky to me but Instagram's real time API is not very intuitive to work with.
Related
Issue:
First API calls only returns top 3 posts.
The next_url returns no data(data array is empty and pagination string is null)
The 4th post is suspect because I am unable to get it with API calls and it is not returned in the first API call.
Details:
Using v1/users/self/media/recent endpoint
Using Javascript to loop through calls, using "next_url" for the 2nd and subsequent call.
Using Access Token
Worked fine(returned all posts) until "the 4th post" was made
Why do I think one specific post is the issue? Because I am unable to retrieve it using the API. If I set the max_id to this post id, then I get all other posts before this post.
If I leave max_id out, the first call gets all posts newer than this post.
Verified that I am not in a Sandbox.
Has anyone encountered this before? and why would one post be breaking the next_url API call? Is there something in the post causing this?
I can't give out the IG account, sorry I know that would help, but it needs to remain private.
I am a developer on a project that makes extensive use of the legacy Instagram API. It has, for a long while now, been extremely flakey. We have experienced your exact issue many times and there is no practical solution.
However, all Instagram APIs have now (finally!) been migrated to Facebook. You should use the new Instagram Basic Display API which will be properly supported going forward.
I am making a timer job in c# which will make a call to office 365 and fetch newly created users. For example, if I run it now it should fetch users since last run till current time (Delta). However I dont see any FILTER or API parameter where I can pass date and get ONLY those users who are updated or created after specific date.
Is there any API available something like this;
https://graph.windows.net/{MYORG}/users?api-version=1.6&[Filter=createdDate
gt 12/12/2016 or modifiedDate gt 12/12/2016]
Azure AD Graph API can't do this as far as I am aware of, the User entity does not contain creation or modification dates to query on.
However, the beta endpoint of the Microsoft Graph API should be able to do this. You can follow the instructions here: https://graph.microsoft.io/en-us/docs/concepts/delta_query_users. Simply put you must:
Call the users endpoint with the delta function
If you got a skip token, it means there are more pages
Fetch the next page until you no longer get a skip token but get a delta token instead
This delta token allows you to call the endpoint anytime later to get only the modified users (created/updated/deleted)
General guidance for delta queries
I found that blog already however its under delta and throwing errors to me. Here is what I got in response of first call;
https://graph.microsoft.com/beta/users/delta?$skiptoken=
when I did a GET to that link, I am getting error saying the resource you are trying to request is either does not exist or has been removed or...
I feel there is a bug as its beta API.
However, good news is I just found another blog which seems to have be fixed my problem using following query;
https://graph.windows.net/XYZ.onmicrosoft.com/directoryObjects?api-version=1.6&deltaLink=
I will anyway mark your answer as accepted assuming Microsoft will fix the issue I am getting from backend.
I've been using Instagram's min_tag_id for a while now without any major problems. Recently I realized that I stopped getting new content after a while.
For example when looking for tags/chicken/media/recent the first time, I get a bunch of posts and a min_tag_id like AQC8xyA5c5TTZycztD0Y3pb5ECQ7BbDUN-UPvGeN_ki-rroC3YbV4UH9Hr44UK4cAaKfRb5e1hWCyYqECiMiwG2XUnP5-6-F8MW7jCPSMZIgVqbPn9_HIZyhtOT3isPopSU.
I store this min_tag_id in a database and use it few seconds later to make a new request to the API - to get new content.
But somehow, after some time, Instagram won't deliver me new content anymore.
Then I have to delete the last min_tag_id and make a new request without it. Instagram will of course respond with a bunch of posts I already know, but also with a new min_tag_id which will work again for some time.
I cannot reproduce the problem just yet, it just happens. Sometimes it takes a few hours, sometimes it seems to be a few days.
Does anyone know why this is happening or even have a solution that does not include deleting the old min_tag_id sporadically?
I found the error I made. I only stored the min_tag_id when there was content delivered by Instagram. But when there where no new posts, I considered the request as "not successful" and didn't care to store the new min_tag_id.
Instagram sends a freshly generated min_tag_id for every request, regardless if there is new content or not. One always has to use the new min_tag_id, even though the "old" id still works for a while. Apparently the "old" min_tag_id will expire at some point.
when i'm accessing the instagram API via the https://api.instagram.com/v1/tags/nofilter/media/recent and i click refresh on the browser, it seems to get more posts, but the count doesn't change on the app in iOS or on the API. Is there actually more posts being posted or is it just cycling through old ones?
There is a maximal limit of returned media per request: 33 (by now). By default the API should return 20 items. Regardless of refreshing the browser, the number of posts per request does not change.
I assume that you were getting the same number of media after refreshing the browser, but they were new, just being posted on the Instagram. However, they could have more data (longer descriptions etc.), which could give you an illusive impression of more fetched items.
Current scenario
I have build an application that harvest Instagram images from a specific hashtag.
I use the pagination to fetch all images, and store the data (not the images) locally in a database. The first invocation of the app harvest all images. Subsequent invocations only harvest those newer than the newest image in the local database. Otherwise I would need to make thousands of request to page through all images on popular tags. And that would need to be done every few minutes, if images where to appear without too much delay in the app.
The problem that arises is that when users put tags on old images, these images are then not fetched by my app - because of the only-fetch-new-images performance construct.
Attempt at solution
I looked at the realtime API, but is seems to me it is constructed in a way that makes it unsuable. This is what it sends in a realtime update for a tag:
{
"subscription_id": "2",
"object": "tag",
"object_id": "nofilter",
"changed_aspect": "media",
"time": 1297286541
}
I would have thought that there would be a list of media IDs, representing the new/changed content, from which I could fetch the actual content - but there is not.
My current solution is to fetch new content every few minutes, and then doing full rescans every hour. This is suboptimal both from a user, and a performance perspective.
Question
Is it really not possible to do in a more elegant way? I appreciate that Instagram does not send the full content in the realtime update, but sending the IDs should not be a problem in terms of payload-size. It seems like the API is pretty useless in this regards - the only use-case I can think of, where it would be of any use, is for a "There is new content on you hashtag watch" nofications.
Best,
Torben
What I do with geography search is that everytime I get a update package I query the recent geography endpoint. This works quite well. Im guessing thats the idea with tag subscription aswell, have you tried querying the recent instagrams tag endpoint?
/tags/[tag-name]/media/recent
Paginate the recent media for a tag with the min_tag_id parameter to sort the result based on when it was tagged and not when the photo was taken. We use this in combination with the realtime api at silarapp.com and it works fine.
From the Instagram Api Documenation (my emphasis):
Get a list of recently tagged media. Note that this media is ordered by when the media was tagged with this tag, rather than the order it was posted. Use the max_tag_id and min_tag_id parameters in the pagination response to paginate through these objects. Can return a mix of image and video types.