We will be just an integrator providing DocuSign services to our clients that have DocuSign accounts via OAuth authentication in our application. Some of our clients will have significantly higher volume than others.
If we set the RequireAcknowledgement flag on the envelope's event notification and the initial post to the webhook url fails (due to server down, etc.) for account 1 (low volume client) and then a subsequent post succeeds (server back up) for account 2 (high volume client) will the post for account 1 be retried or would they have to wait for the indeterminate time (could be hours or days) between requests for their account?
In other words, is the retry tied to the individual account having a successful post or to our integrator key or notification url having a successful post?
The retry logic is based on the Connect subscription (also known as the Connect configuration.)
If you're creating a Connect subscription at the account level then each account has its own subscription. (Even though the same Integration Key is being used.)
If you're using the per-envelope eventNotification technique for creating per-envelope subscriptions, each envelope is a different subscription.
Details on the retry logic.
Related
Is there any way to implement a Webhook for automatic update of subscriptions on server side, in nodejs for example, for situations such as: the user renewed or canceled his subscription?
Currently I save the subscription data in my Database after purchase and use the Google Developers API to verify that it has been renewed or canceled when necessary.
However, for some Administrator routines I need to check all subscriptions at once and this includes calling the Google API for each one. This process is slow and can take a long time.
I could create a method that checks and updates all subscriptions according to the Google API response, and leave this process running through a Cronjob every day at night. I believe it will work, but a server-side Webhook would be the ideal solution.
Something which automatically notifies my server as soon as there is a change to a subscription so that I can update it in my DB immediately.
Found the answer. We can use Google Cloud Platform (GCP) to subscribe to topics and receive real-time notifications when a subscription change.
All steps are described in detail in their documentation: https://developer.android.com/google/play/billing/getting-ready#configure-rtdn
I am using the official DocuSign java client 3.2.0. I have set the envelope level notification as listed below. Say the webhook URL is https://A.
EventNotification eventNotification = new EventNotification();
eventNotification.setIncludeHMAC("true");
eventNotification.setIncludeDocuments("true");
eventNotification.setRequireAcknowledgment("true");
eventNotification.setUrl("https://A");
EnvelopeEvent envelopeEvent = new EnvelopeEvent();
envelopeEvent.setEnvelopeEventStatusCode("completed");
eventNotification.setEnvelopeEvents(Arrays.asList(envelopeEvent));
envelopeDefinition.setEventNotification(eventNotification);
I am trying to test the retry logic for this webhook. After few successful push requests, I intentionally made the service to return non 200 code (Example 404) for one of the request. Then I reverted the logic, so that the service continue to return 200 response for new requests.
I checked after more than 24 hours, the failed request was never retried.
Is there any reason why the request was never retried eventhough there were successful requests after the failure?
I also have a connect listener configured to push the complete notification for all the envelopes to webhook URL https://B
Currently we have come issue with this webhook URL, so all the push notification to https://B is getting failed.
Is the continuous failure with the https://B connect webhook stop retries to envelope level notification webhook https://A ?
Also Is there any difference between the connect retry vs envelope notification retries?
For for global account events (all users and envelopes) make sure "Require Acknowledgement" option is selected in your Connect settings for the specific webhook for the failed to be re-pushed.
Connect webhook is global (all users and envelopes) for the account and you can select when is triggered for example "Envelope Sent", "Envelope Voided" etc. In this way you can have multiple webhooks handling different account events.
In your case you are setting webhook notification only for the specified envelope.
Also this could help you
https://developers.docusign.com/docs/esign-rest-api/reference/Connect/ConnectEvents/
Connect retries at the account level for Aggregate Messages (the default) after 24 hours after a subsequent message is sent. I will ask about envelope-level connect retries.
Better is to switch to Send Intermediate Messages (SIM) queuing. It retries faster.
Best is to have a 100% always up listener (server). An easy and cheap (free) technique for this is to use AWS PaaS to receive and enqueue the messages. See blog post and sample code. We also have sample code for Google Cloud and Azure.
Is there any configuration present in Azure B2C to limit the number of verification emails ( used for email verification during create account & reset password workflows ) sent to users in a specified time window aka rate limit. We want to prevent malicious actors email bombing our customers with these verification emails.
You can add a retry limit in the selfasserted page if using Custom Policies. It will force the user to be sent back to the app, and they have to try the process again.
setting.retryLimit
https://learn.microsoft.com/en-us/azure/active-directory-b2c/self-asserted-technical-profile#metadata
The service itself has some throttling limits on how many can be sent from a particular IP within a certain timeframe.
I am working for the first time with Stripe. I am using stand alone accounts. I have a platform account also. In my web site a number of people with different Stripe accounts will be opening up campaigns for which money can be donated by various donors. Each campaign owner has a separate stripe account and the platform will be charging through the campaign owner's stripe account.
So what it amounts to is the platform account will be charging for a number of campaigns through each campaign owner's Stripe account. My problem is related to web hooks. One point to remember is each campaign has an id associated with it in the database and I am storing the API key of each campaign owner's stripe account and associating it with this id. To get Stripe data from the web hook in the web hook end point I have to set the API key of the connected account with a statement like:
\Stripe\Stripe::setApiKey("api key of stand alone account");
$input = #file_get_contents("php://input");
The trouble with this is there is one web hook end point for a number of Stripe accounts. I cannot hard-code the API key in the above statement. I have to fetch the appropriate API key from my database using the id.
But when Stripe invokes the web hook end point I simply do not have the campaign id with me in order to fetch the appropriate API key and set the API key. Is there any solution around this?
You don't need to store each account's API key. The only information you need to store is the account ID ("acct_..."). With standalone accounts, your integration will receive the account ID in the last step of the OAuth flow, in the stripe_user_id parameter.
You can then issue API requests on behalf of this account by using your own (the platform's) API key, and the Stripe-Account header.
Regarding webhooks specifically, events sent to your server via a "Connect" endpoint will include a user_id field with the account ID. So you can do something like this:
\Stripe\Stripe::setApiKey("PLATFORM_API_KEY");
$input = #file_get_contents("php://input");
$event_json = json_decode($input);
$user_id = $event_json->user_id;
// if you need to send an API request on behalf of this account,
// for example if you want to verify the event by fetching it from
// Stripe, you can use the Stripe-Account header:
$event = \Stripe\Event::retrieve(
$event_json->id,
array("stripe_account" => $user_id)
);
Now I'm using PushSharp library to send Apple push notifications (through APNS), but I want to migrate to Notification Hubs for robustness and scalability.
I'm planning to implement sending notification via Azure Notification Hubs using backend registration as described in this article. So:
There is a method of backend API that an iOS client calls when it has push token updated. In this method I do the registration tagging it with user id. (Previously, I stored push token to user link in DB.)
When I have some notification to send for a specific user I send it using the tag (user id). (Previously, I used APNS device token from DB.)
It seems like a working solution, but in Notification Hubs documentation it's said:
It is important to note that registrations are transient. Similar to the PNS handles that they contain, registrations expire. You can set the time to live for a registration on the Notification Hub, up to a maximum of 90 days. This limit means that they must be periodically refreshed, and also that they should not be the only store for important information. This automatic expiration also simplifies cleanup when your mobile application is uninstalled.
And that is the problem. Sometimes I need to send notification to devices that haven't updated the token for 90 days and so forth the registration. So the APNS token will still be active, but Notification Hub's registration will be invalidated. So I just lose the communication channel for the user.
How do you handle this?
Of course, I can still store tokens in DB and make a job that updates registrations periodically. But that's not what you expect from a push notification solution like Notification Hubs.
You can either refresh your registrations from the application or from your server. If you do it from your application, the app must be launched by the user in order for the registration to be refreshed.
Therefore, if you require that device registrations remain active even for apps that weren't launched for over 90 days, you have to refresh the registration via your server, and running a job in your server that would refresh the tokens seems like your only option.
I agree that Notification Hubs' decision to expire the tokens seems strange. Perhaps they had in mind the behavior of MPNS (Microsoft Push Notification Service) notification channels, which expire more often than APNS device tokens or GCM registration IDs.
Just a quick note, since the answer is 2 years old. In this blogpost Azure states:
It is important to note that registrations and installations by default no longer expire.
I assume that this makes the expire field confusing, but not a problem anymore.
UPDATE
Older notification hubs still have this issue. You need to update them to set the expiry to infinity, instructions are found in this forum post. New hubs are automatically set to infinity.
As per latest notification hub documentation, this 90 days limit has increased to lifetime, which means you don't need to re register device after 90 days.