When making a request to the POST /groups/{id}/events endpoint, the Microsoft Graph API sometimes returns a status code 429 error response, indicating that too many requests have been made in too short a time period and that requests are being throttled. Based on my observations, it appears this throttling limit applies based on the intersection of the authorization token used, as well as the specific group ID specified in the request: changing either seems to bypass the throttling constraint.
However, to my surprise and in apparent contradiction to Microsoft documentation, these POST requests seem to succeed in spite of the failure response. My application utilizes change notifications to receive webhooks when new events are created in Outlook. A couple seconds after receiving the 429 error response, I receive a notification indicating the successful creation of the event sent via POST request.
Request timestamp: 2020-03-19T11:04:22.784-07:00
Webhook timestamp: 2020-03-19T11:04:24.833-07:00 (successful creation notification)
What I'm trying to figure out is, should I be expecting this behavior from all Graph APIs? Just Outlook-related? Just Group calendar-related? Just POST requests? Retrying these requests will create duplicates, so I need to know how to best handle these errors.
Going off that, any guidance to specific throttling limits for Group calendar APIs, or advice on how to avoid them, would be welcomed.
Related
As per sendgrid documentation, the way Inbound parser webhook responds to failures are that it will retry to post the email to the configured endpoint for 3 days and will drop the email if undelivered.
The Parse API will POST the parsed email to a URL that you specify. If a POST is unsuccessful, SendGrid automatically queues and retries any POSTs that respond with a 5XX status. This prevents data loss for customers who have misconfigured their website or POST URL.
Respond with a 2xx status to the POST request to stop the email from retrying.
To avoid returning an error your link must return a 2xx HTTP code when the email is received. This response lets our system know that your link has received the email. It is then removed from our send queue. If we do not get a valid 2xx HTTP response, our servers will believe they have failed to deliver your message. Messages that cannot be delivered after 3 days will be dropped.
I would like to know if before dropping the undelivered emails, will sendgrid notify the sender that their email could not be delivered?
Based on a few tests I ran, it does not appear SendGrid will ever send a notification to the sender, nor is there any easy way to ascertain whether SendGrid has dropped any inbound emails.
Although the documentation wording is slightly ambiguous, my understanding based on testing (which aligns with the documentation wording) is this:
Server returns 2xx: email is deemed accepted, no further attempts made.
Server returns 5xx: server has error, attempts made until 2xx is returned (see below for timing of subsequent attempts), or 72 hours lapses
Server returns any other response, or DNS records do not exist: email is deemed failed, no further attempts made.
My conclusions are based on a number of tests I ran over the course of a week, from which I ascertained the following:
Case 1. Parse server returns 400 or 403 error
The email is dropped after one attempt.
No further attempts are made to POST the email.
No notification is sent to the sender or to the SendGrid account.
(Test method: Configure SendGrid to a URL that returns one of the above error codes. Checked server logs over 1 week, and noted only one attempt was made.)
Case 2. The parse hook URL does not have a DNS record
The email is dropped, presumably after one attempt.
No notification is sent to the sender or to the SendGrid account.
(Test method: configure the hook URL to a subdomain that does not have any DNS records. Run DNS search and try opening the hook URL to confirm the DNS records do not point anywhere. Send an email. Then, after 12 hours, add an appropriate record to the subdomain to point it to a script. Checked server logs and confirmed no attempts were made to POST the email. A subsequent email attempt successfully POSTed.)
Case 3. Parse server returns 500 error
SendGrid attempts to POST to the hook URL at the following intervals:
+0 +5m +10m +15m +20m
+25m +35m +50m +1h20m +2h20m
...then every 3 hours
The last attempt occurs +71h20m
The 20 min offset is a bit unusual, but it falls on the hour, so it may be because the message is queued to attempt POSTing on the hour.
No further attempts are made to POST the email after 72 hours.
No notification is sent to the sender or the SendGrid account.
Statistics
The documentation refers to the availability of statistics, however, I have found the numbers to be inaccurate.
For example, during my testing, I had a number of emails go through the API, including some that were intended to be successful (and did indeed POST to my server) and a few that were intended to fail (as part of the above testing), however, the numbers returned did not align.
Takeaways
Care should be exercised in the following scenarios:
Server downtime: this would ultimately depend on how the server is configured. If the server returns a 5xx response code, SendGrid will keep trying to POST the email. I also tried to test a timeout scenario, however, SendGrid seems to be very patient (e.g. I made my script pause for 10 minutes, SendGrid kept the connection for 10 minutes, though interestingly, due to the second attempt occurring after 5 mins, the email POSTed twice).
Server misconfiguration that returns 4xx error codes. SendGrid will drop the email.
It should also be noted if an email is dropped, there doesn't appear to be any reliable method of finding this out.
SendGrid won't send a notification before the email is dropped. However, the message will be dropped only after receiving an error from your Webhook URL and retrying to post the message for three days.
We got a confirmation from the Sendgrid support team, that the emails that are dropped in the Inbound Webhook Parser feature, will not have any notification or being saved in Sendgrid. So, we won't be able to get any info regarding the emails which are dropped.
I'm testing the Mandrill API and sent an email to my GMail account. In the API logs, it says:
"status": "queued"
According to https://mandrill.zendesk.com/hc/en-us/articles/205582717-Why-does-a-delivered-message-say-queued- :
most times Mandrill can send email much faster than recipient servers
are able to accept or process it
GMail is not able to handle my one email that I sent?
A queued response in the Mandrill API is not the same as a queued response from a recipient server.
When you send a message through Mandrill, you first relay it to Mandrill, Mandrill processes it, and then Mandrill relays it to the recipient server. This all happens quite quickly, but the two relaying steps are separate and distinct. The KB article you've linked to is providing additional details on that last step, relaying to recipient servers, not a queued status for the Mandrill API.
There are a number of reasons the Mandrill API may respond with queued including if you've added attachments or if you're sending to a bunch of recipients in a single API call.
Without seeing the actual API call that's being made, it's hard to say why you're getting a queued response. But if you're using the sample messages/send API call, you'll want to remove all of the optional parameters that you're not actually setting. For example, the sample has fake attachments, and a subaccount specified. The attachment will cause the call to be processed async. The subaccount probably doesn't exist, and would then cause the call to fail. So if that's the case, try removing all of those optional params. If not, please provide the API call you're making with sensitive data redacted (API key, actual email addresses).
The reason might be either hourly/monthly quota is over or you are using same multiple accounts for single public ip server.
I am using free mandrill account and sending email via using template and API
When i send message it returns okay it is sent as status
However even after several days there is still no smtp events at mandrill interface and the email is not arrived
So i am 100% suree mandrill is ghosting accounts
Or there is something else that i do not know?
Thank you for answers
PS: At the beginning emails were arriving but after some point no smtp events and no emails ever arrived even though no error message parsed. Also when i send to non existing email no bounce message returned.
Also account reputation is 61 : excellent
Yes i believe mandrill certainly ghosting accounts
After trying with several accounts i am now sure of it
Even if you send to non existing gmail email, it says delivered in its interface
However it should have displayed hard bounced
So beware of their free service. I believe this is not an ethical way of working. People would think that their emails are arriving however they are ghosted and mandrill did not even try to send them and yet displays delivered
Have you check it on Mandrill account? It shows all the report at outbound tag. The reason is, a queued response in the Mandrill API is not the same as a queued response from a recipient server.
When you send a message through Mandrill, you first relay it to Mandrill, Mandrill processes it, and then Mandrill relays it to the recipient server. This all happens quite quickly, but the two relaying steps are separate and distinct. The KB article you've linked to is providing additional details on that last step, relaying to recipient servers, not a queued status for the Mandrill API.
There are a number of reasons the Mandrill API may respond with queued including if you've added attachments or if you're sending to a bunch of recipients in a single API call.
Without seeing the actual API call that's being made, it's hard to say why you're getting a queued response. But if you're using the sample messages/send API call, you'll want to remove all of the optional parameters that you're not actually setting. For example, the sample has fake attachments, and a subaccount specified. The attachment will cause the call to be processed async. The subaccount probably doesn't exist, and would then cause the call to fail. So if that's the case, try removing all of those optional params. If not, please provide the API call you're making with sensitive data redacted (API key, actual email addresses).
We are getting internal_failure error message while exchanging code to get refresh token. This error doesn't occur all the time for all the accounts. This happens only while authenticating with a few Google accounts and that too like 5 to 6 failures for every 10 authentication requests no matter what the client_id is. We have a test account and is reproducible too frequently in this account as well.
{
"error" : "internal_failure"
}
How often are you making these requests? You are probably running into the per account quota limits.
In real life, any account would not be doing a lot of code to refresh token conversion. The expectation is that you do that just once per application.
So, if you have test/monitoring accounts, they will run into these issues. The best is for you to monitor and test only your site/code.
internal_failure is an authentication server outage. which can be tracked on
Cloud Status or apparently also APP Status although I am not seeing it there it may only be GSuite issues are there.
There is nothing that you can do but wait for the server to return.
I'm using eventbrite.com, and I'm trying use the rest API to get all the previous events for my user (organizer in eventbrite). I am expecting to get events that have occurred in the past.
I'm using the following url:
https://www.eventbrite.com/xml/event_search?organizer={MyOrganizerName}&app_key={MyAppKey}&date=past
However, I get nothing returned. ever. I am sure that have some events that happened in the past.
I am successfully getting events in the future. so there's nothing wrong with my client\app key\spelling\whatever.
With the newer Eventbrite APIv3 the endpoint changed to /users/me/owned_events The API comes with an API Explorer, which lets you see detailed debugging information for any endpoint just by going to it in a web browser.
Paste this url with your token id into your browser to get all past events:
https://www.eventbriteapi.com/v3/users/me/owned_events/?token=YOURTOKENID
The result is a paginated response of all the events your user account is organizing.
The event_search method is meant to return publicly available information about upcoming events only.
Try user_list_events instead:
https://www.eventbrite.com/xml/user_list_events?app_key={YOUR_APP_KEY}&user_key={YOUR_USER_KEY}&event_statuses=ended
You also have the option of creating an Organizer Profile Page, allowing you to group similar events together. The organizer_list_events API call may be useful for folks who are using that feature.