I have experienced significant variability when using the Instagram Subscription API. For the most part, the API will not post updates to my end-point as specified during the subscribe initiation. My understanding is that the subscription is configured correctly as any of the updates from my personal account are received.
There seem to be reports across the web talking about significant delays. However, it is my experience that accounts that work do so within seconds but in most instances no subscription messages are never received.
There was discussion on the web also regarding queuing of updates sent through to the subscribe API. Which may make a little sense, however a queue would suggest that updates would be received eventually.
I have requested basic permissions, which is sufficient to request public media from each registered account. Yet, there I have a gut feeling that these permissions could be the problem, so I have started the process of requesting public_content.
At this stage there seems to be a number of developers experiencing similar issues, yet no resolutions.
Has anybody been able to resolve this issue?
I'm subscribed to aspect=media object=user and experiencing a similar issue.
For some users, I'm notified 95% of the time. For other users, I've never been notified of a single post.
In this post nithinisreddy mentions that the data is being "sampled". I think this is the reason. Hopefully it improves after the tags/locations subscriptions are deprecated.
Related
This is part public awareness and part actual question for better workarounds.
Overall, we have recently discovered (the hard way) that emailing via an Azure Action Group is unreliable and occasionally fails. Basically, sometimes their IPs get blacklisted for various reasons (very common). They have nothing in place to alert those relying on an email notification that it failed, even though they have all the information they need to do so (they showed me a screenshot showing the SMTP failure due to the IP blacklisting from their log). The Azure portal will still show "fired". And, so, it just fails silently in the background with no indication to the user it was never sent. According to one of the technical Azure reps we have discussed this with:
The way of identifying a failure is to evaluate any kind of rejection message received from the target server but those are not guaranteed and not generated in all scenarios. Take into account that email actions are provided free of charge and performing post-send operations to try and verify delivery would consume additional computing that would make providing this notification mechanism free of charge less desirable
I know that many rely on these for production notifications of various scenarios. You should not rely on this going forward, or at least have a backup in place (e.g. SMS, web-hook, etc).
I would like to know if anyone has experienced this as well and, if so, what is the better, more reliable method to use.
Thanks in advance!
I am using UPS APIs to figure out ratings and create shipments and now I'd like to track shipments in real time. I know there are a lot of services that provide tracking aggregation for different couriers, including UPS, via webhooks, but I am looking for a "native" UPS API for the real time tracking that would not require me to keep poling for updates.
I went over the UPS API docs and could not find anything. Is there such an API that offers webhook type notifications or something similar in UPS? If not, how do those services like EasyPost, ParcelMonitor, TrackingMore and others can offer such functionality?
I'd like to track shipments in real time
"Real-time tracking" is a misnomer in the shipping technology industry. EasyPost does provide webhook events to notify you of updates, but those updates will never come in "real-time" and no tracking service provider should ever make such a claim. There will always be some kind of delay between when the carrier updates their system and when the updates are able to flow through providers like EasyPost. The delay may be short, but any delay at all means that "real-time" goes out the window.
Being an EasyPost employee myself, I have to disclose my bias and say that I believe EasyPost can help you get updates as promptly as possible for UPS shipments.
The nice thing about setting up webhooks with EasyPost is that you don't have establish your own logic to repeated poll for new tracking updates. This can save you network bandwidth and reduce the complexity of your code and it can help you get updates sooner than if you were trying to poll updates on your own intermittent schedule.
I'm working on a project in the Google Cloud App Engine (node.js flexible runtime) and while I've had a pretty good experience with it thus far, I've recently ran into a problem where the engine will sometimes not respond a specific pubsub notification. Sometimes, the results will appear after a few minutes, but often times it requires me to redeploy the app and lose any messages that I had queued up prior. Interestingly enough, when I send a pubsub message through a different subscription, the engine responds to it well. The backlogged messages are then handled, but sending the problematic message again will still not work.
I'm not really sure how to solve this issue. There is no evidence that google received the message from pubsub in the logs. Additionally, waiting for this long will have negative impacts on the project overall, implying that the messages will reach the end destination given enough time.
I'm willing to provide more information to help reproduce the error.
Thanks in advance
Edit The issue has increased significantly in severity. Please see the updated post I made to see the current extent of the issue.
While researching Azure Notification Hubs, I saw there are two Telemetry options available (source):
"Limited"
"Rich"
Although I have found very limited descriptions on the Pricing and the FAQ pages, this is not enough information to make a decision whether I want the "Rich" telemetry or if the "Limited" Telemetry is enough. Additionaly, those descriptions only talk about the "Rich" option:
Standard namespaces have access to Per Message Telemetry and Push Notification Services Feedback
Rich telemetry: You can use Notification Hubs Per Message Telemetry to track any push requests and Platform Notification System Feedback for debugging.
Also, a Tweet asking #AzureSupport for help only lead to the FAQ page and eventually led them to ask me if I could ask this very question on SO.
The only option available next to asking here is to actually try out, but that would incur a monthly fee and extra effort.
The main difference between the two is that "limited" gives you access to counts of various events: registrations, sends etc; pretty much everything you see as graphs in Azure Portal on Notification Hubs blades.
"Rich" (or Per Message Telemetry) gives you access to detailed information about every single push: things like feedback from PNS and many other things. You can think about it as if you were to send requests directly to PNS yourself and log pretty much any meaningful information about those.
Let me know in the comments if I can clarify.
I finally found a useful MSDN page, which has some answers to what telemetry is provided, how, and to who. It says "This API is only available for Standard tier notification hubs" which means Rich Telemetry only, not Limited.
If the PNS platform involved supports it, then Success means it was delivered to the device. Oddly, despite copious other error codes, there seems to be none for "accepted by PNS, but still not/failed to deliver to device."
It provides counts of outcomes, so if you want per-device results, you'll have to send to only to one device at a time.
I've been using instagram's real time push api (http://instagram.com/developer/realtime/) for a long time to get updates on a specific location. I use the highest possible value for "radius", which is 5000m . For the last 4 weeks, I have noticed that I received significantly less updates through the API (but not zero). Other applications seem to have the same issue, like http://now.jit.su/ . I also filed a bug report at instagram, which went unanswered.
My questions are:
- has anything changed in the API?
- has anything changed in the app (so that not every photo will be published)?
- is anyone else experiencing this issue?
- is there anything I can try to get it working again?
I know this is not exactly a perfect SO question, but I was not able to dig anything up on google, and the instagram developer pages direct here for support. Any help is greatly appreciated.
Had some communication recently with a contact at Instagram and he mentioned that Instagram's real-time functionality will be limited to only user subscriptions in the future.
Apps created before November 17, 2015 will continue to receive updates but are being sampled because of the load they are experiencing and the fact that the architecture used for this does not scale well. He also mentioned that, as a result, real-time subscriptions will be deprecated for Tags, Locations and Geographies.
The developer guides also have some information regarding this:
OLD: https://www.instagram.com/developer/deprecated/realtime/
NEW: https://www.instagram.com/developer/subscriptions/
I am using https://api.instagram.com/v1/users/self/feed?access_token=AccessToken&count=100 to get my feeds.
You might be missing count in your api or let me know which api you are using