I created a webhook I let ran on my forge application. Webhook is "system": "derivative", on "event": "extraction.finished".
After a few weeks, hook was not triggered anymore.
When I query it to check what was going:
webhook is still present
But, I now have "status": "inactive" (it was active at creation time)
I got no feedback why this hook was disabled (only way to figure it out is by being reported my main app was broken from users).
What can deactivate a webhook? is it expected?
Current workaround I have so far is re-create the webhook, which comes back with active status. Unfortunately, this is definitely a short-term solution since I do not know when it will move to inactive again.
Thank you,
Webhook status can be set to inactive if callbackUrl is failing too often (cf. comment from Xiaodong Liang "When webhook tried a couple of times but no any response, it will disable this webhook").
(In my case there was a place in my callbackUrl that was returning 500.)
Thanks
I would recommend this class of Autodesk University: Seamless integration with Forge Webhooks. This class talks about some notes on Webhook such as SLA:
Working on formal SLA
Delivery Guarantees
At least once
Ordering is not guaranteed
Responsibility of Callback URLs
Callback URLs have fixed time window in which to respond (~10 secs)
Best Practice - Return 202 and process asynchronously
3 Retries done, 15 minutes apart
Final retry 24 hours later
If none succeed, we will disable the WebHook
Latency
HTTP Latency: Ideally suited to coarse grained events
In addition,I'd recommend another note of Webhook: signature. I have some practice and this is the blog:
https://forge.autodesk.com/blog/practice-payload-signature-webhook
Related
Im in the process of trying to promote an Integration App to our production DocuSign environment, but receiving the following error.
"Excessive polling does not comply with DocuSign"
Here's the endpoint we are calling with from_date filter and a custom field. The from_date and the clientID custom field values change for each request that is made. Yet we still get the excessive polling error. The DSACCOUNTGUID value does not change.
https://demo.docusign.net/restapi/v2.1/accounts/{DSACCOUNTGUID}/envelopes?from_date=2020-09-21T15:33:08.160Z&custom_field=clientID=1201
Can someone tell what we are doing incorrectly? Thanks ahead of time.
Can
From this article
Polling rate limits
For any specific envelope, polling status requests are limited to once every 15 minutes.
To avoid excessive polling, you can specify a span of time to poll in each Envelopes: listStatusChanges or equivalent listStatusChanges SDK method call. To ensure that you don’t miss any changes, we recommend that you request overlapping times in your polls or subscribing to Connect to get status updates for the envelope.
You should consider using webhooks instead.
The ListStatusChanges call will generally trigger a polling violation if it is called more than once every fifteen minutes.
What query string parameters are you using and how often are you making that call?
We create PaymentIntents (with capture_method=manual in case that matters) in our iOS/Android apps when the user places an order.
We send the order to the connected venue once the charge.succeeded webhook fires. If this doesn't happen within a couple of minutes, we expired the placed order on our side.
So interestingly 2 out of 10 times we don't get this webhook to fire.
Im wondering if it's actually wise to listen to this webhook in order to decide if we send the order to the connected account's venue or not or if there is a better way to determine that the payment will actually work once we try to capture it.
Webhooks are the recommended way for getting a payment intent's status, but you can also use the API to get its status.
A quote from the Stripe docs:
It is technically possible to use polling instead of webhooks to
monitor for changes caused by asynchronous operations—repeatedly
retrieving a PaymentIntent so that you can check its status—but this
is markedly less reliable and may pose challenges if used at scale.
Stripe enforces rate limiting on API requests, so exercise caution
should you decide to use polling.
In your case, I'd recommend waiting for the webhook and then after a few minutes, call either the PaymentIntents API or the Charges API if you haven't received the webhook yet.
There's likely something else going on here, so I'd suggest you reach out to Stripe - webhooks should fire all the time, and it's a really really rare occurrence that they wouldn't.
I'm updating a webapp to Stripes SCA ready flow with PaymentIntent.
So far I have working (on my local test server):
Generate Intent on frontend and pass secret to form
Use Elements to collect card into
Use handleCardPayment to create the charge
Now here's the part where I am unsure. The handleCardPayment responses all seem to indicate a succeeded event, but the documentation warns to not use this repsonse, but instead wait for the Webhook response and only then fulfill customer orders.
Step 5: Asynchronously fulfill the customer’s order
You can use the PaymentIntent returned by Stripe.js to provide
immediate feedback to your customers when the payment completes on the
client. However, your integration should not attempt to handle order
fulfillment on the client side because it is possible for customers to
leave the page after payment is complete but before the fulfillment
process initiates. Instead, you will need to handle asynchronous
events in order to be notified and drive fulfillment when the payment
succeeds. Documentation
So far so good, I've set up test webhooks and tunneling through ngrok I can actually receive the paymentIntent from the Stripe webhook.
Now, my question comes at this point, where the Stripe documentation ends. How should I deal with the UI from the point of the "Pay" button being pressed, and how do I in the frontend detect that the webhook has been triggered?
I am wondering if I should poll my own server, which in turn retrieves a database result that indicated if the webhook for this order has been received? Or what is a reasonable way to deal with this, technically and from an UX perspective?
Any pointers?
I just implemented this, and I decided to poll my own server for the update and ask the user to wait. The webhook marks our internal representation as "paid", so we don't need to poll Stripe. If the webhook doesn't come within 30 seconds, we tell the user that it's ok to leave the page, and we'll email them the result.
Technically, these webhooks can take up to 7 days to come in, so that's why Stripe doesn't want you to have the user wait. In reality, it almost always comes in within 5 seconds, and I would rather just have the user wait and see a final confirmation in the same session.
I have successfully created a Glip bot in the sandbox and registered the corresponding webhooks, following the instructions found here: https://ringcentral-api-docs.readthedocs.io/en/latest/glip_bots/
When testing in the sandbox, I only get a webhook payload about 50% of the time when the bot is spoken to in a conversation. I would expect to get one every time, since the bot has a subscription for posts, and is a member of that group. Additionally, if the subscription wasn't working at all, I would expect to get it 0% of the time. Literally the same text will trigger it once, but not the second time.
I determined that there was nothing wrong with the endpoint by using Postman to simulate webhooks. Every time I created a simulation, the bot became aware of the post and responded accordingly. So it isn't the endpoint. It would appear that RingCentral Glip is not calling the endpoint every time it should.
It could potentially be a sandbox issue but I don't see any documentation that supports that theory. The specific event that's not firing every time is "/restapi/v1.0/glip/posts". As I continue to investigate I thought I'd reach out to see if anyone else experienced this issue, or has suggestions on how to debug.
My fulfillment needs to do a lot of processing after receiving a certain request from Google Action/API.AI and the default response timeout is 5s.
https://developers.google.com/actions/components/fulfillment#nodejs
Is there any way I could send a delayed response or send a POST request after the results are ready?
The short answer is no - you must respond within 5 seconds, and there is no way to send a notification back through the Assistant at this time.
The slightly longer answer is that we know notifications are coming - but we don't know if there will be an API for them. There have been rumors about other ways that may be coming that allow us to work around the 5 second limit.
The even longer answer is that, if you are using Action Transactions (ie - allowing the user to purchase or reserve something) you can send updates after the fact. However, Transactions are still in developer preview and don't work on all surfaces (they don't work on Google Home at all, for example).