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 am using Twilio and I want to get the DateSent parameter of a message. When the message is initially sent it has null values for both DateCreated and DateSent. So I pass a StatusCallback URL to receive any status updates on that message. However, I am able to get only the new statuses the message gets such as sent, or delivered and not the new date as an event. In the docs I couldn't find anything about this either (https://www.twilio.com/docs/sms/send-messages#monitor-the-status-of-your-message). What is the way to get this information without continuously polling the API?
The date created is included as part of the response from the API. If you find that is not the case can you please post example code.
When the sms is actually sent you can pull the message resource using the api or sdk via the sid https://www.twilio.com/docs/sms/api/message-resource#fetch-a-message-resource
I had taken backup of my mail box using below rest API
GET https://graph.microsoft.com/v1.0/me/messages
But from My side this email msg deleted and i want to restore it again .
How i can do it using Rest API.
I tried with
POST https://graph.microsoft.com/v1.0/me/messages
and body with message.
but the message added as a draft not actual message.
Please help.
That is correct, when you create an email it will always save as draft unless it has been sent.
Try find the returned message id from the message creation POST, then issue a secondary POST to send it:
POST https://graph.microsoft.com/v1.0/me/messages/{id}/send
Ref: message: send
I am trying to build a local database storing Twilio SMS message events. There would be two tables: A Messages table with message info (To,From,Body,etc.), and a StatusRecords table containing status events (Status,ErrorCode,ErrorMessage, etc.). Both tables would be keyed on the MessageID.
I can get the MessageID and message info when I send a message (as a client) using the REST API in the returned response. That's fine.
I have a java servlet running that is called with status updates when Twilio updates the message delivery status. I then update the status in my database using the MessageID as the key. That's fine as well.
I have another servlet running that receives reply messages. I pick up the reply MessageID and add this to the database. This servlet also replies to the incomming message in the http GET response parameter using the TwilML API.
The problem is: How do I get the MessageID of the reply to the incomming message? The reply takes place as a result of a response to the http GET. I don't think I will hear from Twilio again after responding.
I assume that Twilio will update the status on the reply message as it is delivered or not delivered--and I will receive this update in my status update servlet. I could probably try to match the phone number of the status update to get the reply MessageID but this seems sort of crude.
Is there a more elegant way to do this?
Twilio evangelist here.
The <Message> verb takes an action parameter which lets you specify a URL for Twilio to request once it processes the Message noun. This request will include the Message SID.
If you wanted to associate the SID of the incoming message with the one sent by Twilio, you could pass the incoming message SID as part of the URL you set for the action parameter:
http://example.com/message?id=XXXXXXXXXX
Hope that helps.
I'm new to twilio and have the following situation. I want to send an SMS to someone for an appointment confirmation. They'll text back CONFIRM or CANCEL etc to the message.
Is there any way to pass an internal database id in the SMS to them and get it back in their response so i know what they're confirming or canceling? I'd rather it not be shown to the end user receiving the text.
Thanks!
Twilio evangelist here.
Unfortunately there isn't any way to transparently include metadata in an SMS and have that metadata returned to you when they reply, but there ways to address your scenario.
If you are sending the user a text message you already have their phone number and you can use that as a unique ID. When the user replies to your message, Twilio will as part of our HTTP request to your application, pass you the users phone number. You can use that number to locate them in your database and mark them as confirming or canceling.
Hope that helps.