I tried the facebook analytics_app_events_exports graph api.
I got the id as response and checked the status for 3-4 hours. Still the status is SCHEDULED.
The documentation says schedule will change to RUNNING and then to COMPLETED within 2 hours which in my case didn't happen.
Any insights on this to how to proceed with this? Any forum or dev support where I can raise this request?
The status was updated as completed after 2 days. I believe heavy traffic must be the reason for the delay
Related
In testing code that uses the SendGrid Email Activity API, I have received "too many messages" errors. I have examined the "rate limit" response headers and it appears that I am being limited to 10 requests per 5 minute block in the day. That is, the first 5 minutes of every hour can have 10 requests, the next 5 minutes can have 10 requests, etc.
I asked SendGrid support about this. The first response was pretty generic, but seems to indicate that the threshold is correct and says I really should be using webhooks to get the status. I haven't found anything in the documentation saying this and I haven't seen anything the specifies what the rate limits are.
For those of you using the Email Activity API, are you limited to 10 requests per 5 minutes? If yes, what do you do with the API?
Here's an snippet of what I ended up using with requests, tenacity and ratelimit:
from ratelimit import limits, sleep_and_retry
import requests
import tenacity
#sleep_and_retry
#limits(calls=2, period=60)
#tenacity.retry(
retry=tenacity.retry_if_exception_type(requests.exceptions.HTTPError),
stop=tenacity.stop_after_attempt(10),
wait=tenacity.wait.wait_fixed(60),
)
def _call_api(headers, params):
response = requests.get(
"https://api.sendgrid.com/v3/messages",
json={},
headers={},
params={},
)
try:
response.raise_for_status()
except requests.exceptions.HTTPError:
logger.info(f"Request failed {response.headers}, retrying in 1 minute")
raise
return response
I received a response from SendGrid support that says:
Your findings are correct in that we do limit this endpoint to 10 requests per 5 minutes. This is a hard limit that we do not have the means of raising. The Email Activity Feed as well as the Email Activity API endpoint are meant for troubleshooting specific issues and attaining detailed message metadata.
I previously found the rate limit to be 10/5min but it appears that SendGrid have changed the rate limit to 2 requests every 60 seconds sometime in the past week. Can anyone confirm this?
I'm using the webhook to report non-delivery back to my application but I also need to use the activity API to resolve async bounce notifications. Async bounces are when a destination mail server accepts a message during the smtp session but subsequently sends a bounce notification email. When this occurs, SendGrid do not provide the detail of the bounced message in the webhook and the message is incorrectly reported as delivered in the SendGrid app. When asked, they respond that there's nothing they can do about it, even though I have explained to them how I use their activity api to resolve this.
I pay extra to use the activity API to fix a problem that they should address themselves, so I'm very frustrated that they apply such restrictive rate limits, then change them without notice.
I've inherited a Facebook webhook application written in Node that tracks posts for several Facebook pages associated with our organization. On 2017-07-02 (about 3 weeks ago), it appears Facebook stopped pushing webhook updates to this application. This application had been running successfully for the last couple years prior to this.
These are the last entries I see in our application's access log:
724661:173.252.105.118 - - [02/Jul/2017:16:40:23 -0700] "POST /callback/facebook HTTP/1.1" 200 5 "-" "Webhooks/1.0"
724662:66.220.145.151 - - [02/Jul/2017:16:55:29 -0700] "POST /callback/facebook HTTP/1.1" 200 5 "-" "Webhooks/1.0"
724663:31.13.114.11 - - [02/Jul/2017:16:55:30 -0700] "POST /callback/facebook HTTP/1.1" 200 5 "-" "Webhooks/1.0"
I have confirmed that our application is still functioning by sending a manual request using curl that it did successfully process.
I see here that Facebook marked availability of v2.3 of their API to end on July 8:
https://developers.facebook.com/docs/apps/changelog
In the upgrade guide for v2.3 to v2.4, it notes:
There are a number of Page permissions changes between v2.3 and v2.4 that your apps will need to account for. Notably, a Page access token is now required to interface with /v2.4/{page_id}/promotable_posts, /v2.4/{page_id}/offers, and /v2.4/{page_id}/milestones.
Is this why Facebook has stopped pushing updates to our webhook endpoint? If so, where can I find more information on using Page access tokens with webhooks?
Facebook will stop sending updates to your webhook callback URL after a while, if your app is not responding with a 200 status code quickly enough. In such a case, you have to set up your callback URL again.
This is - somewhat - documented under
https://developers.facebook.com/docs/messenger-platform/webhook-reference#response,
Your webhook callback should always return a 200 OK HTTP response when invoked by Facebook. Failing to do so may cause your webhook to be unsubscribed by the Messenger Platform.
It is extremely important to return a 200 OK HTTP as fast as possible. Facebook will wait for a 200 before sending you the next message. In high volume bots, a delay in returning a 200 can cause significant delays in Facebook delivering messages to your webhook.
It does not explicitly mention this here, but I am pretty sure failing to respond with a 200 in a certain amount of time is also considered a failure.
Even less real-time related tools such as the Facebook Scraper (that grabs the Open Graph meta data from links shared by users) have a timeout of 10 seconds; so Facebook's patience for webhooks is not gonna be any longer, likely rather (much) shorter specifically for Messenger platform related webhooks - those response times directly influence the user experience after all.
Edit: You realized you actually asked about Graph API webhooks, not Messenger platform. But it is similar for those - https://developers.facebook.com/docs/graph-api/webhooks#callback
If any update sent to your server fails, we will retry immediately, then try a few more times with decreasing frequency over the next 24 hours. Your server should handle deduplication in these cases. Updates unaccepted for 24 hours will be dropped.
Response
Your endpoint should return a 200 OK HTTPS response for all update notifications.
And from discussions in the FB developers group I know that repeated timeouts also cause un-subscription from the webhooks in this case.
I booked a ride, moved it to ACCEPTED state, and tried to cancel it by updating the ride status to rider_canceled. In both cases, I get message stating that it are not valid product status.
Also, after requesting a ride, I tried moving to no_drivers_available, got the same error.
Any clues why ?
You shouldn't have any issues updating the status to "driver_canceled". If that's still a problem for you, can you post some example code?
For "rider_canceled", you need to make a DELETE request for that request id. From https://developer.uber.com/docs/sandbox#section-other-request-statuses:
rider_canceled - The Request canceled by rider. Issue a DELETE command to give a Request this status
For eg: ride was in progress for 1 day ! Or ride was accepted, but neither the rider or driver, it any action on it. Does this generate webhook callback ?
I am using sandbox-api as of now. My ride just expires after some time(1 hour may be) and I get ClientError when trying to get the ride details. On rebooking, I get a new ride id. I do not know if webhook is firing callback or not, as I do not have a CA certificate as of now on my server listening to callback. Will this happen in production api also ?
Unfortunately our sandbox isn't perfect and doesn't mimic production behavior 100%. In the production environment a trip in the "processing" stage is cancelled after around 2 minutes if no suitable driver is found.
Regarding the duration of a real trip...I don't think we have any hard limit on that. If the driver and passenger mutually agree to keep the trip going, then the trip keeps going.
Webhooks will be fire for all trip status changes (i.e "processing" to "accepted" etc)
Hope that helps!
Best,
Richie
Regarding this API: https://developers.google.com/admin-sdk/email-audit/#accessing_account_information
I have been using the Admin SDK to retrieve login history for users in our Google Apps for Business setup. When I request individual users at a time, the request sometimes takes a few hours to process (in which the state is PENDING). However, when those few hours pass, I still get the login history that I need.
The problem continues as I begin requesting more users. We have around 750 users, and of those 750~ requests I made, 725 gave me an error after waiting ONE WEEK for my requests to be processed. Even worse, the ones that did not error out are still pending! Here is the response I get when I check the status of a request that errored out:
{'status': 'ERROR', 'adminEmailAddress': '***#etsy.com', 'requestDate': '***', 'requestId': '***', 'userEmailAddress': '***#etsy.com'}
This has got to be the flakiest and most unreliable API I have ever been unfortunate enough to work with. Requests can take anywhere from an hour to over a week to process, with no indicator of success in the mean time. Errors can also happen for no apparent reason, and no messages or explanations as to why.
It looks like this issue has been resolved by the Google Engineers. Try to run the calls again. It shouldn't be in pending more than the "normal" expected time. I just tried earlier, and I was able to export login info for my users.