how to recieve exception for deleted event from recurring event in outlook rest api - outlook-restapi

I am using Outlook push notification API to receive events from the calendar.
When an event is deleted from recurring event, I get a notification with type 'updated'. But I do not get the information of the deleted event. How can I get the information about the deleted event?

Related

Docusign Connect Audit Events

DocuSign webhooks sends 1 envelope per message. It can also return the respective child entities if they have been configured so (e.g. documents, recipients).
I wanted to receive audit events of the envelope (when someone opened or viewed) in the message as well.
Is it possible? Or is it only possible through polling? What is the recommended strategy?
The DocuSign webhook notification messages are sent per webhook event. There are events at the envelope level (Draft, Sent, Delivered, Completed, Declined, or Voided) and for each recipient (Sent, Delivered, Completed, Declined, AuthenticationFailed, and AutoResponded).
The audit event of a recipient viewing an envelope is available as the Delivered recipient event.
There are other audit events which are not available as webhook events. To track those you'd need to poll. Remember the DocuSign limit of polling no more often than once per 15 minutes per envelope. (And the overall API limit of 1,000 calls per hour.)
If you subscribe to the recipient.Delivered event then you'll receive a webhook message when a recipient views the envelope. See the Delivered date stamp for the recipient and the Delivered status.
BUT if you have the webhook system set to aggregate notification messages (the default) then individual notifications may be aggregated together. For example, if you're subscribing to both the recipient delivered and completed events, and a recipient opens (delivered) and then immediately signs (completed) the envelope, you may only get one notification, for the later (completed) event.
But your code can look for the delivered date stamp to see if the envelope was delivered.

At which stripe event should I update my db to grant subscriber access

I have a SaaS MERN app which is using Stripe for subscriptions. I'm using the new checkout feature of Stripe to handle all the payments. I have the stripe CLI installed to see the events that occur when a subscription is made. I have a few questions regarding the events that are emitted and how to handle them in my stripe webhook.
Which event below indicate that the payment was successful so that I can update my database.
Why is it that the payment_intent.succeeded occurs before payment_intent.created.
Why is a customer.subscription.updated event happening (I'm assuming it should just be the customer.subscription.created event that should occur on first purchase)
I use the customer.subscription.updated event in my webhook to allow customers to turn autoRenewal on and off. Because the customer.subscription.updated event is also shot off at initial payment when subscribing, how can I differentiate what to do as the same event is fired off in both cases.
This is not as important, but if anyone knows what that POST error is at the bottom, I would appreciate some insight. [EDIT] I fixed this by moving my res.status(200).json({received: true}) further up my code. Initially it was placed at the very end of my webhook, so I think it was timing out.
Thank you :)
If you specifically want to provision the subscription on successful payment, then you should listen for payment_intent.succeeded
Stripe doesn't guarantee the order of webhook events, it's possible to receive them out of order: https://stripe.com/docs/webhooks/best-practices#event-ordering
The subscription's status would be updated to show that the latest invoice was successfully paid, which triggers and update event
You probably want to use invoice.upcoming instead: https://stripe.com/docs/api/events/types?lang=java#event_types-invoice.upcoming
You'd have to debug this on your end to see where it came from. Looks like perhaps your local server wasn't running and so the Stripe CLI couldn't forward on the webhook event.

How to recognize which calendar the event belongs in Microsoft graph api?

I am developing application that synchronize with microsoft calendar.
To get any changes on Microsoft calendar I use webHook service and every time receive new/deleted/updated events but I do not know which calendar the event belongs, even after I get full event from Microsoft and not only the ID.
There are many calendars for user!
How can I recognize id of calendar?
The event resource has a calendar relationship, so that you should be able to do:
GET /me/events/{event-id}/calendar

Docusign connect: what is the envelope event triggered when sender selects "Discard" action?

A sender has an option to discard an envelope.
I'd like to get a notification when that happens. So I subscribed to "Voided" event but have not been able to receive notification from the Docusign connect when sender discards an envelope.
Any feedback is appreciated.
Roman
Are you referring to the Discard Changes action, as shown here?
If so, there is no DocuSign Connect event notification that correlates to this sender action.
If the Sender were to click Discard Changes in the process of creating a new Envelope (i.e., one that hasn't yet been saved or sent), there wouldn't be an envelope to associate the event notification with (because the Envelope ID isn't created until it's Saved or Sent).
If the Sender were to open an existing Envelope via the DocuSign UI (i.e., either a Draft Envelope that has never been sent or an In-Process Envelope that is pending action from one or more recipients) and click Discard Changes before sending or saving, there wouldn't be any Connect event notification triggered because there was no change in Envelope state.

DocuSign Connect (Delete Signers)

I am not receiving events for Delete of signers.
Is this an expected behaviour of DocuSign Connect?
These are my steps:
Log in as sender and created the envelope with 4 signers
Click on the email link as the signer and opened the envelope
Signed the envelope as the signer
Log in as sender and deleted one of the remaining 3 signers (This is missing from my Connect event)
I received XML messages for steps 1-3.
However, there was no event trigger for step 4.
I am monitoring this under both Connect Logs and Failures.
I have every event enabled under my Connect Configuration.
Is it expected to not receive an event in this case?
If not, any suggestions on how I can debug why I am not receiving messages?
Just another finding:
An event is triggered for the New Experience.
This behavior is only observed for the Classic Experience.
I believe the behavior you're seeing is by design. i.e., the "Recipient Deleted" action does not correlate to any of the events that can trigger a DocuSign Connect notification. The events that can trigger a DocuSign Connect notification are shown in the Connect configuration UI:
As this screenshot shows, there is no event that correlates to the "Recipient Deleted" action.
If your application needs to know if/when a recipient is removed from an Envelope, you could implement a process that periodically polls in-progress envelopes (List Envelope Recipients) with the goal of detecting if/when a recipient has been deleted. This obviously isn't ideal, as it wouldn't be a real-time notification, but it's likely your only option, given that DocuSign Connect does not currently support notifications for "Recipient Deleted".
UPDATE #1
Interestingly, I've verified the behavior that you've described in your Comment below. I tested the following scenario in both the "New" UI and the "Classic" UI:
Created/sent an Envelope with 2 recipients (sequential routing order: 1, 2)
Immediately thereafter (i.e., while still pending response from the first signer), I corrected the Envelope to delete the second recipient (routing order=2).
Conducting the steps above using the "New" Smartsheet UI triggers a Connect Notification ("Envelope Sent"), while conducting the exact same stepsusing the "Classic" Smartsheet UI does not trigger any notification. This behavior inconsistency seems like a bug to me -- perhaps someone with DocuSign can chime in to confirm/explain.

Resources