[GH-ISSUE #58] Feature request: expose liked post URLs via webhook / notifications (best-effort) #41

New issue

Open

opened 2026-02-27 20:05:07 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 20:05:07 +03:00

Owner

Originally created by @webreplicax-stack on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/misiektoja/instagram_monitor/issues/58

Hi 👋 first of all, thank you for this project — it’s very well built and extremely useful.

I’m using instagram_monitor mainly to track follower changes, and it works great for that.
I noticed that the tool is also able to detect “likes” activity internally (visible in the dashboard / activity feed), but currently there doesn’t seem to be a way to consume this data programmatically.

Feature request (best-effort / optional)

Would it be possible to expose liked post events (even in a best-effort or experimental way) via one of the existing output channels, for example:

webhook payload
notification system (Telegram / JSON)
or a simple event callback

What would already be very useful:

post URL (e.g. https://www.instagram.com/p/XXXX/)
target username (optional)
timestamp (if available)

I fully understand that:

Instagram activity feeds are unstable
likes are ephemeral and rate-limited
this may not be 100% reliable

Even partial / recent / non-guaranteed data would still be valuable for monitoring purposes.

Use case

I’m using this for personal monitoring of a small number of public accounts (non-commercial), mainly to:

see recent likes
forward them to an external system (webhook → notifications)

If this is out of scope for the project, no worries at all — just wanted to ask in case it’s something you’d consider or have thoughts about.

Thanks again for your work on this project 🙏

Originally created by @webreplicax-stack on GitHub (Jan 28, 2026). Original GitHub issue: https://github.com/misiektoja/instagram_monitor/issues/58 Hi 👋 first of all, thank you for this project — it’s very well built and extremely useful. I’m using instagram_monitor mainly to track follower changes, and it works great for that. I noticed that the tool is also able to detect “likes” activity internally (visible in the dashboard / activity feed), but currently there doesn’t seem to be a way to consume this data programmatically. ### Feature request (best-effort / optional) Would it be possible to expose *liked post events* (even in a best-effort or experimental way) via one of the existing output channels, for example: - webhook payload - notification system (Telegram / JSON) - or a simple event callback What would already be very useful: - post URL (e.g. https://www.instagram.com/p/XXXX/) - target username (optional) - timestamp (if available) I fully understand that: - Instagram activity feeds are unstable - likes are ephemeral and rate-limited - this may not be 100% reliable Even partial / recent / non-guaranteed data would still be valuable for monitoring purposes. ### Use case I’m using this for personal monitoring of a small number of public accounts (non-commercial), mainly to: - see *recent* likes - forward them to an external system (webhook → notifications) If this is out of scope for the project, no worries at all — just wanted to ask in case it’s something you’d consider or have thoughts about. Thanks again for your work on this project 🙏

kerem added the

enhancement

label

2026-02-27 20:05:07 +03:00

kerem commented

2026-02-27 20:05:08 +03:00

Author

Owner

@misiektoja commented on GitHub (Jan 29, 2026):

Hi there! Thank you for the kind words and for using the project!

This is an interesting suggestion. You're right that we already capture like counts internally when a new post is detected, which is why you see them in the dashboard. However, at the moment, the tool doesn't watch existing posts for like changes over time - it's more of a point-in-time capture when the post is first found.

It is definitely feasible to expose this data. Since we already have the post URL, username and timestamp logic in place, the main missing piece is a comparison loop that re-checks the most recent posts (e.g. the last 3-5 posts) and triggers an event if the like count increases.

I've noted this as a great candidate for an experimental feature. Given the ephemeral nature of likes and the rate-limiting concerns you mentioned, a best-effort implementation seems like the right way to go.

@misiektoja commented on GitHub (Jan 29, 2026): Hi there! Thank you for the kind words and for using the project! This is an interesting suggestion. You're right that we already capture like counts internally when a new post is detected, which is why you see them in the dashboard. However, at the moment, the tool doesn't watch existing posts for like changes over time - it's more of a point-in-time capture when the post is first found. It is definitely feasible to expose this data. Since we already have the post URL, username and timestamp logic in place, the main missing piece is a comparison loop that re-checks the most recent posts (e.g. the last 3-5 posts) and triggers an event if the like count increases. I've noted this as a great candidate for an experimental feature. Given the ephemeral nature of likes and the rate-limiting concerns you mentioned, a best-effort implementation seems like the right way to go.

kerem commented

2026-02-27 20:05:08 +03:00

Author

Owner

@webreplicax-stack commented on GitHub (Jan 29, 2026):

Thank you for the detailed explanation — that makes perfect sense.

Your approach sounds exactly like what I had in mind. A lightweight comparison loop over the most recent posts (e.g. last 3–5), with a best-effort event when the like count increases, would already be extremely useful.

I completely agree that this shouldn’t aim for perfect accuracy given rate-limits and the ephemeral nature of likes. Even partial or delayed detection would still add a lot of value for monitoring purposes.

If this ever moves forward as an experimental feature and you’re open to feedback or testing, I’d be happy to help on that side. Either way, thanks again for considering the idea and for maintaining the project.

@webreplicax-stack commented on GitHub (Jan 29, 2026): Thank you for the detailed explanation — that makes perfect sense. Your approach sounds exactly like what I had in mind. A lightweight comparison loop over the most recent posts (e.g. last 3–5), with a best-effort event when the like count increases, would already be extremely useful. I completely agree that this shouldn’t aim for perfect accuracy given rate-limits and the ephemeral nature of likes. Even partial or delayed detection would still add a lot of value for monitoring purposes. If this ever moves forward as an experimental feature and you’re open to feedback or testing, I’d be happy to help on that side. Either way, thanks again for considering the idea and for maintaining the project.