> For the complete documentation index, see [llms.txt](https://docs.mdintegrations.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mdintegrations.com/partner/troubleshooting/technical-concepts/webhook-event-catalog.md). # Webhook Event Catalog This page catalogs the confirmed webhook event names MDI sends, grouped by what they relate to, so you know what to build listeners for. Payload field-level detail for events owned by another guide — pharmacy orders, offering submission — lives on those dedicated pages instead; this catalog cross-links to them rather than duplicating that detail here. ## General payload convention Every event carries a Unix `timestamp` marking when it occurred, and that timestamp stays consistent across retried deliveries of the same event. Use it — not the time you received the delivery — to dedupe and order events correctly, since retries can arrive out of order relative to when they originally fired. See Retry Policy & Idempotency for the full retry behavior. {% hint style="info" %} Your server should respond with a `200 OK` status as soon as it receives the payload. Acknowledge first, then process asynchronously — don't make MDI's delivery wait on your business logic before you return `200`. {% endhint %} ## Identity & intake events | Event | Fires When | Typical Use | | --------------------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `voucher_created` | A Voucher is generated. | Anchor timing for intake-abandonment reminders. MDI's own default reminder emails use this timestamp to drive a 4/24/48-hour cadence — useful context if you're replacing those reminders with your own. | | `drivers_license_requested` | The patient needs to upload a driver's license for ID verification. | Prompt the patient to complete ID verification if you're not embedding MDI's own upload UI. | | `file_upload_requested` | A file is needed from the patient, generally. | Surface a file-upload prompt in your own UI. | | `exam_requested` | A clinician or workflow is requesting the patient self-report an exam or vitals. | Prompt the patient to complete a self-reported exam. | | `intro_video_requested` | The patient needs to submit their AV/intro video as part of state AV-sync requirements. | Prompt the patient to record and submit their intro video. | ## Messaging events | Event | Fires When | Typical Use | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `message_created` | A message is created in the Patient Channel or Support/Internal Channel, from either the patient or the clinician/support side. | Push "your doctor replied" notifications, sync messages into your own inbox or CRM. Requires filtering by sender — see the note below. | {% hint style="warning" %} `message_created` fires for messages from both the patient and the clinician/support side using the same event. Always filter on the sender before treating an event as a "new message from the doctor" notification — otherwise a patient's own message can trigger a notification telling them their doctor replied. See Message Types & Notifications for the full filtering pattern. {% endhint %} ## Case (Encounter) lifecycle events | Event | Fires When | Typical Use | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | `case_waiting` | An Encounter moves into the `Waiting` status — the physician is waiting on the patient for something. | Prompt the patient to complete whatever's outstanding before their case can move forward. | | `case_completed` | An Encounter reaches the `Completed` status. | Notify the patient their case was reviewed, trigger any downstream logic tied to case completion. | | `offering_submitted` | A case is approved and prescription/service data is ready. Covered in full, including payload fields, in the pharmacy integration docs. | Kick off downstream billing, inventory, or fulfillment workflows. See Pharmacy Webhooks & Order Sync. | ## Pharmacy/order events | Event | Fires When | Typical Use | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `case_order_created` | A pharmacy order tied to an Encounter is created. Covered in full, including payload fields, in the pharmacy integration docs. | Mirror new pharmacy orders in your own admin tools. See Pharmacy Webhooks & Order Sync and Partner-Owned Transmission. | | `case_order_updated` | A pharmacy order's status changes as it moves through fulfillment. Covered in full, including payload fields, in the pharmacy integration docs. | Mirror fulfillment and shipping status in your own admin tools or customer-facing order history. See Pharmacy Webhooks & Order Sync and Partner-Owned Transmission. | ## Where to find exact payloads Field names and JSON shapes for every event above are maintained in the Webhooks section of the Full API Reference (hosted in Postman) — treat that as the source of truth for exact payload structure rather than relying solely on this catalog. If you want to see a real payload without waiting on an actual physician, patient, or pharmacy action, use the **Test Bench** to simulate these events on demand. See Test Bench for how. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.mdintegrations.com/partner/troubleshooting/technical-concepts/webhook-event-catalog.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.