Reputation: 20409
Currently I use /users/self/media/liked
method, get the response, read next_max_like_id
and request the data again and again. I've tried to pass huge count
value, but looks like max count value is just 30
.
I need to track changes in the number of media user liked. Is there any way to optimize it? I don't understand well what next_max_like_id
means? Is there any way to keep it and use it next time somehow?
Upvotes: 4
Views: 1582
Reputation: 401
next_max_like_id is for paginating to next set of likes data. You have to pass it to your next consecutive request. As Instagram API returning limited results, you can use this facility.
Upvotes: 0
Reputation: 369
The request limit for users/self/media/likes
is 33 (default is 20). The next_url
that's returned in the pagination section will grab the chronologically preceding liked items, using the same count
(if you've supplied one) and next_max_like_id
, which is the id of the last result returned.
If by "track changes" you mean keep a running tally, as far as I know you can't access the total number of liked items via an endpoint. You'd have to write a script that scrapes like history, using the paginination info to jump backwards until you can see you've hit the original like by catching on a duplicate next_max_like_id
(side note: the data returned only includes posts that the user still has access to).
If you have a lot of users, you'll have to stagger your queries with a cron job for the original scrape since there's a limit of 5000 API calls per hour. Once that's complete you could have a last_id_liked
field in your database for continued count maintenance.
The only optimization I can offer is instead of counting returned results you can count the number of times you jump backwards and multiply by the count... but you're still using up an API call each time.
Upvotes: 5