> ## Documentation Index
> Fetch the complete documentation index at: https://docs.connect.fastenhealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Use Webhooks to listen to events from Fasten Connect, rather than polling the API.

## Why Use Webhooks?

When building applications using Fasten Connect, you'll need to configure a webhook to receive events.
Since collecting medical records from Health Systems can take time, webhooks allow you to wait for the data to be available,
without wasting time and resources by polling the API.

To enable webhook events, you need to register a webhook in the [Developer Portal](https://portal.connect.fastenhealth.com).
Fasten Connect uses HTTPS to `POST` webhook events to your app as a JSON payload that includes an Event object.

## Payload Overview

All webhook payloads contain a common set of fields wrapping the event data. The `event` object contains the event type and the data associated with the event.

```json theme={null}
{
    "api_mode": "test",
    "date": "2024-06-13T00:08:31Z",
    "id": "c0ac7bc4-c6ef-4f0b-bba3-93506774eb74",
    "type": "patient.ehi_export_success",
    "data": {
        "download_links": [{
          "url": "https://api.connect.fastenhealth.com/v1/bridge/fhir/ehi-export/fedec7b7-8cf6-4bc9-72032b426473/download/2024-06-12-6715-4ae4-bde5-ab97519bd1fa.jsonl",
          "export_type": "jsonl",
          "content_type": "application/fhir+ndjson"
        }],
        "task_id": "fedec7b78cf6905872032b426473",
        "org_id": "592c0579-c1cc-443f-a94e-4c8847c0c066"
    }
}
```

<ParamField path="api_mode" type="string">
  The Fasten Connect API has two modes: `test` and `live`. Test mode is used for development and testing, while live mode is used for production.
  This field will always be present in the payload and will indicate the mode of the API that generated the event.
</ParamField>

<ParamField path="date" type="string">
  This will be an [RFC3339](https://www.rfc-editor.org/rfc/rfc3339.html#section-5.8) timestamp that encodes the date & time the payload delivery was attempted.

  **This may not be when the event was created.** The timestamp of the attempt may be different to the timestamp of the event that generated the attempt.
  One common example of where this happens: failed deliveries. Every time an attempt is retried the timestamp of the attempt
  is updated, while the timestamp of the original event remains the same. The attempt's timestamp as an important security measure meant to prevent replay attacks.
</ParamField>

<ParamField path="id" type="string">
  The `id` is a UUIDv4 that uniquely identifies the event. This is useful for idempotency, to ensure that you don't process the same event multiple times.

  It remains the same no matter how many times a webhook that has failed is retried.
</ParamField>

<ParamField path="type" type="string">
  [Event Types](/webhooks/events) indicate the type of the event being sent in the webhook and the schema of the `data` field.
</ParamField>

<ParamField path="data" type="object">
  See `type` and [Event Types](/webhooks/events) documentation to find out what fields are present in the `data` object.
</ParamField>