feat(api): send webhook to cx when doc query is complete #250
Conversation
docs/home/api-info/webhooks.mdx
Outdated
|
|
||
| Webhook requests contain the relevant information on the body of the HTTP request. | ||
|
|
||
| There are three types of messages you can expect to recieve: |
| // if this is for MAPI: | ||
| // silently ignore this since this is just a notification for ease-of-use | ||
| // and won't result in data loss |
There was a problem hiding this comment.
Is there a benefit of not enabling retries for doc references? Just trying to gauge the cost/effort of doing it vs the added complexity to the API by having diff behaviors based on the API the customer is using.
If we keep like this, I think we should document it on the retry section of webhook docs.
There was a problem hiding this comment.
So the logic here is that:
- this is only not enabled if the cx doesn't have the WH URL set
- if they don't have it set, that means they don't have the endpoint implemented yet
- there should be no benefit of retrying these payloads after they implement the WH, as they will be able to get the same data using the mechanism they previously used, and only new data will be sent
Lmk what you think
There was a problem hiding this comment.
^ to be explicit, the retries will still function as expected if the cx has the WH url setup
There was a problem hiding this comment.
if they don't have it set, that means they don't have the endpoint implemented yet
One might delete the API key after setting it up.
there should be no benefit of retrying these payloads after they implement the WH, as they will be able to get the same data using the mechanism they previously used, and only new data will be sent
That assumes they would implement GET /document, but in theory customers could only implement webhook, as it sends all the document references we have for a given patient, right?
There was a problem hiding this comment.
As discussed offline:
- We will retry doc refs, if the failure reason is for something other than them not having a WH url set on the dash. The logic here is that if they don't initially (let's say they choose not to implement WH in their flow), when they turn the switch on, they'll get a bunch of old doc refs that they should have already processed, so they'll have to filter those out or something - trying to avoid those situations.
- Good point as to what if they change/remove the URL after it has already been setup once though - will document this limitation for now and iterate based on cx feedback
|
🎉 This PR is included in version 4.4.0-develop.8 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
refs. #242
Dependencies
N/A
Description
send webhook to cx when doc query is complete + update docs accordingly.
Release Plan
nothing special