July 13, 2017 at 10:28 am
In doing some testing in my sandbox, I noted that if I submit a package with a signer with an invalid email address, early the next morning I got a delivery failure notification to my email inbox.
I’m curious if there is a way to actively monitor email delivery status via the API? I’ve looked over the package JSON looking for a field along these lines (something like an “emailDeliveryStatus”), but I’m not seeing anything.
Does anyone know if such a field exists or if any other email delivery status monitoring options are available?July 13, 2017 at 11:10 am
There is no way to retrieve the delivery status of an email through the API. What I can suggest is to create a callback listener and subscribe to the EMAIL_BOUNCE event. If you don’t receive any notifications that an email has been bounced, you can be pretty much assured that the email has been sent.
Also, the reason why you received the failure delivery email the next morning is because you entered an invalid (non-existing) domain. In these cases, you’ll receive the bounce notification the next day. However, if the domain is correct but the user incorrect, you’ll receive the bounce notification within minutes.
eSignLive Technical EvangelistJuly 13, 2017 at 1:22 pm
Haris – thank you for the info! An event-based solution is actually preferable to the type of solution I was asking about in my original question, so this is perfect!
Many thanks – I’ll take a look!July 13, 2017 at 3:09 pm
One interesting thing I noted in reviewing those docs – is it true that the only way to see these events is through setting up a ‘callback’ via one of your SDK options?
Put another way, is there a way to subscribe/view/query/etc events directly via the SignLive API, or is using one of the SDKs are only option?July 13, 2017 at 3:46 pm
The easiest way is actually through the UI, but you can definitely set the callback URL, key, and subscribed events through the REST API. If you look at this guide, you’ll see how to locate this in the UI and how to use the REST API to set it up.
Hope this helps.
July 13, 2017 at 4:43 pm
Ah! Thank you!
My apologies – I am well familiar with that set of documentation, but I completely overlooked that particular entry. I’ll take a look!July 14, 2017 at 1:09 pm
OK, hand a chance to review all of this information and it looks like a really nice option – this should fit our needs nicely (and then some!)
One follow up task our security people had for me is to follow up with eSignLive to find out what the origin of these callback POSTs will be, as they would like to build a firewall rule in front of the API we stand up to receive them.
Does anyone have some advice on how to track that information down?July 14, 2017 at 5:23 pm
Take a look at this post:
Whitelisting the IP from your instance of eSignLive should take care of that for you.
Be sure to check out the Callback Key setting as well. That key will come via the auth header on the http call so you can verify that eSignLive is who actually sent you the notification.
July 14, 2017 at 5:47 pm
Holy smokes, you guys are on it – thank you!
My only hope is that you don’t get tired of repeatedly telling me to “read the docs…search the forums…read the docs…search the forums…” 😀July 15, 2017 at 12:20 am
Haha! Don’t worry, we won’t get tired of helping! 🙂
Have a great weekend!
July 17, 2017 at 4:36 pm
We’re forging ahead with implementing an endpoint to receive callbacks on, but an interesting question came up –
If you guys aren’t able to get a successful POST to go through (like if our service is down or if there were some sort of network issue), I assume that you retry in a bit – correct? Meaning, if our service was temporarily down, we wouldn’t miss out on any events (we’d receive them all once the next successful POST came through).July 18, 2017 at 10:43 am
If the esignlive application isn’t able to make a successful POST request to your callback URL, you will be notified via email. The esignlive application will not retry to make a post for the same event.
eSignLive Technical EvangelistJuly 18, 2017 at 11:49 am
Cool, thanks for the info – we’ll design accordingly.
So, are those events just lost then? Or is there some other mechanism by which we can go out and learn about them?July 23, 2017 at 8:58 pm
Just a bump to see if anyone has an advice on this.
Assuming we’ve setup an endpoint to allow eSignLive to POST events to us, my understanding is if that endpoint is for whatever reason unavailable, we’ll be notified via email that eSignLive was unable to deliver events to us. My question is what happens (if anything) to those missed events? Is there some sort of alternate mechanism available for us to receive those, or is it a “at most once” delivery paradigm from the eSignLive perspective?
Thank you!July 24, 2017 at 10:06 am
Once you receive the email notification for a callback failure, eSignLive will not resend or attempt to resend that specific event and there isn’t a possibility to retrieve it.
eSignLive Technical Evangelist
- This reply was modified 2 months ago by Haris.
You must be logged in to reply to this topic.