My team is working on an app where we are experimenting with creating an event directly on a meeting room's primary calendar like POST https://outlook.office.com/api/v2.0/users/{meeting room email}/events, and pending a successful response, subsequently PATCHing the event with the desired attendees. However, I've found that I invariably get a 201 even if the meeting room has a conflicting event. Is there a way to get the API to tell me synchronously if there is a conflict? We are trying to avoid the case where you create the event as a real user with the room as an attendee and get a success, only to find that the room auto-rejects the invitation some seconds later.
Related
I'm subscribed to stripe webhook charge.refund.updated event. On that event, I need to attach specific metadata to stripe refund entity (accounting needs this data in stripe exports so I need it there), but this causes same charge.refund.updated event being called again, which causes circular requests.
Only solution I'm thinking of right now is to add some kind of additional ignore field to metadata and then just ignore webhook if that value is true, but I don't really like that solution because it would persist on the refund entity, and if something actually did change on refund, my handler would ignore it.
I guess the best option would be something like stripe.refunds.update(..., { ignoreWebhook: true }), but that's not an option because API doesn't support anything like that (as far as I've investigated).
It’s recommended that you need to design your webhook endpoint to treat duplicates events. Because regardless of your circular call on Charge updates, Stripe occasionally sends the same event more than once [1]. One of the solutions: is to log the event you’ve processed and then not process already-logged events.
In your case, you can add a metadata that contains a version number of the charge. Something like this:
1 - Received an event charge.refund.updated
2- Add your logic along with another version of metadata.
3- You log the charge id, version any other field you are basing your logic while adding metadata (example: status)
4- You’ll receive another event charge.refund.updated, you check if you have already treated that charge based on what you logged already (id, version, status…)
Meanwhile, if you hit the same update charge request API [3] multiple times, only one webhook event is triggered you can test it on your own.
[1] https://stripe.com/docs/webhooks/best-practices#duplicate-events
[2] https://stripe.com/docs/webhooks/best-practices#duplicate-events:~:text=One%20way%20of%20doing%20this%20is%20logging%20the%20events%20you%E2%80%99ve%20processed%2C%20and%20then%20not%20processing%20already%2Dlogged%20events.
[3] https://stripe.com/docs/api/refunds/update
I can see the below point in docusign documentation https://developers.docusign.com/docs/esign-rest-api/esign101/rules-and-limits/
2. Apps are limited to one GET status request per unique envelope per 15 minutes. If you exceed this limit, the request will not fail, but it will be flagged as a violation of rate limits, which can cause your app to fail review to go-live. To avoid exceeding this limit, design your app to poll at 20-minute intervals rather than 15 or, rather than polling for envelope status, your integration can subscribe to Connect to get status updates for the envelope.
My requirement is to poll the documents for each user using API:
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes?count=10&from_date=2021-10-21T04:38:51.0930000Z&include=recipients&order_by=last_modified&order=asc&folder_types=normal,inbox,sentitems,draft&start_position=0
and there documents using API:
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes/<envelope_id>/documents
and I have multiple user connection with same account Id, hitting these two APIs.
will it be flagged as rate limit violation? I have tried these GET api again and again but I can't see this violation status on my client? how can get update of this if in case it happens on my prod instance?
What is the goal of this API call?
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes?count=10&
from_date=2021-10-21T04:38:51.0930000Z&include=recipients&
order_by=last_modified&order=asc&
folder_types=normal,inbox,sentitems,draft&start_position=0
Is it to monitor incoming envelopes? If so you can use Recipient Connect to receive webhook notifications.
Otherwise, for a given DocuSign user, you can make the API call once every 15 minutes or less often.
You cannot make the call more often than once per 15 minutes per associated user. If your app uses a "system user" such as finance#your-company.com then you cannot call it more than once per 15 minutes since the results would not change.
And what is the goal of this API call?
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/
envelopes/<envelope_id>/documents
The documents in an envelope are generally not going to change.
More often, apps want to know when an envelope has completed, and then download the docs.
Update
The polling limits are:
per user
results must be expected to change
This means that you cannot poll after an envelope reaches a terminal state. IE only poll if the envelope is in the sent or delivered states.
And it is still not clear to me why an envelope's documents will change.
If you want to provide the current version of the envelope's documents to your application's user, give them a button to download the documents. Don't poll for them.
Finally remember the limit of 1,000 API calls per hour per account for your application. Your application will NOT be approved for additional API calls per hour with this type of polling activity.
I have a social app where my customer is going to make single purchases (credits/tokens/likes) using a credit card (Visa, Master, Amex, Discover). When the purchase is complete, and I receive a "succeeded" in the result "status" from the Stripe result, the customer will then be given 10, 20, 50, 100, etc. tokens to their profile that can be used now for "liking" someone.
FYI - If the user has a card saved and chooses that card, that Stripe card number and customer number is used for the payment intent, otherwise I'm collecting the card details, and passing that to the "confirmpayment()".
QUESTION - Once I call Stripe "confirmpayment()" client side, and get the result back, which shows the status (succeeded, failed, incomplete, etc.) Is it possible to receive a "succeeded" status in the result and then at some later date via Stripe's webhook, receive a different status other than "succeeded"?
FYI - I've gone through almost all test card scenarios to test for this type of condition, but it doesn't seem like it will happen? It seems like the payment will either succeed or fail on the confirmpayment() call. I'm also double checking the status result on the server side by fetching the paymentIntent from Stripe. Just to make sure the user (client side) hasn't changed it in the code (JS/Typescript).
Concern - The customer finishes their purchase, the confirmpayment result shows a status of "succeeded", their "tokens" are added to their profile at that moment and then they proceed to use them to send "likes" to another user. Then later on I get the Stripe webhook back showing a different status with "failed" or "incomplete". But by this point, "tokens" will have been used and a monetary amount based on the amount of the "token" will have been moved from my Connect account where the original purchased fund will be sent to the intended receiver's connect account. If this happens I foresee it being extremely difficult to back all this out and reverse it will out a huge headache.
ALTERNATIVE WORKFLOW - I could create a "payment" entity on the server side with a pending status and wait until I receive the Stripe webhook before I add any "tokens" to the user account/profile. This will insure there is no possibility for error, but it makes the user wait until the webhook comes in before they will see a status of "success" on their payment page and won't be able to use any "tokens" from that purchase until I get the webhook. I wanted to give them a more instant experience.
Any help or advice will be much appreciated.
The result you get back after the Promise confirmCardPayment() resolves will be the same as the status you get back on the webhook event so it will never be that a succeeded PaymentIntent transitions back to requires_payment_method or requires_action, as succeeded is an end state of the lifecycle.
Keep in mind, webhook events can be out of order, so technically you could get a payment_intent.requires_action after your payment_intent.succeeded event (if they happen very quickly.
The best thing to do is to fetch the PaymentIntent from the API (after an event) to get the "true" state of the PaymentIntent.
We are using a number of webhooks for testing purposes with the DEMO company and this means the webhook queue is full of items.
Is it possible to remove all these items that i am seeing in the webhook queue as i am getting an error about too many requests?
It isn't possible to remove items from the queue manually. That said, once they've been sent and your script has responded correctly they won't be sent again. As such you should just need to allow your script to receive everything in the queue.
Alternatively you could reset your demo company. This will also reset the webhooks and any data you have entered.
I am trying to run the below query and attached is the result of the query. I would like to understand the difference between the conversationupdate, message, event, and endofconversation. Thank you.
customEvents
| where timestamp>ago(7min)
| summarize count=count() by tostring(customDimensions["Activity type"])
Here is the result:
Those are all activity types. You can find a list of activity types in many places, such as here.
conversationUpdate
A bot receives a conversation update activity whenever it has been
added to a conversation, other members have been added to or removed
from a conversation, or conversation metadata has changed.
message
Your bot will send message activities to communicate information to
and receive message activities from users. Some messages may simply
consist of plain text, while others may contain richer content such as
text to be spoken, suggested
actions,
media
attachments,
rich
cards,
and channel-specific
data.
event
Your bot may receive an event activity from an external process or
service that wants to communicate information to your bot without that
information being visible to users. The sender of an event activity
typically does not expect the bot to acknowledge receipt in any way.
endOfConversation
A bot receives an end of conversation activity to indicate that the
user has ended the conversation. A bot may send an end of Conversation
activity to indicate to the user that the conversation is ending.