This feature is still in early adopter status and is subject to change
After following this guide, provide Connective Health with your webhook URL and event types

​
Overview

Webhooks are a technique for informing a system or user of an event that has taken place. This type of architecture is especially helpful for an asynchronous system like Connective Health’s products. Our implementation is very loosely based on the open source Standard Webhooks specification that is in active development. Each webhook is implemented as an HTTP POST to a URL (or URLs) specified by the customer. The basic content of each POST will be this. The type, correlationId, batchId, and timestamp will always be included. The data section is optional, but if specified will contain additional information specific to the webhook type.
Webhook Example
{
  "type": "patient.found",
  "correlationId": "4352bfba-506c-4ffc-b1ba-78e56d0d4ddc",
  "batchId": "35b0b9b5-5e2c-4e86-839e-2551c78132ff",
  "timestamp": "2024-03-25T19:44:46.516663854Z",
  "data": {
    "key": "value",
    "anotherKey": "value2"
  }
}

​
Implementation

​
Event Types

Please contact your account manager if there are other event types you would like to see supported.
Event TypeStatusDescription
patient.insufficientDataAvailableThis event may be due to several issues including the patient not being found or there not being sufficient data for the patient for the data to be delivered
patient.foundAvailableThe patient was identified via one of our connected networks
document.deliveryCompleteAvailableA document (either PDF or FHIR bundle) was successfully delivered

​
Security

Currently, no authentication is supported for the webhook content. The correlationId should be validated against previously sent customer records if necessary. Only https URLs are supported.

​
Retries

Webhooks are processed on a best effort basis. If there is a communication error (anything other than an HTTP 2xx response) then the message will be retried several times with progressively longer time between retries.

​
Special Considerations

​
Missing Delivery

In certain error situations a webhook may not be delivered as expected. This should be rare, but it is possible.

​
Unknown Correlation ID

If your client sends an API request to Connective Health, but the client disconnects or some network error is encountered which prevents your client from receiving the correlation ID, you may then receive a webhook which has a correlation ID you did not expect. Once we have received the HTTP request we will begin processing and generate webhooks (if necessary).

​
Multiple Deliveries

Webhooks are intended to be at least once semantics. While we strive to only deliver each webhook exactly once, for a variety of reasons a single webhook may be sent multiple times. Care should be taken by the receiver to properly handle this situation.

​
Erroneous Delivery

In extremely rare circumstances a webhook may be sent and then later found to be incorrect. An example would be the delivery of a patient.insufficientData webhook being delivered due to a system error, but the patient was in fact found and processed successfully. In this rare case, the webhook may be sent but a PDF is later delivered.