v1.0.7
OpenAPI 3.1.0

Medevio Webhooks

Medevio can notify your system about events in a clinic by sending webhooks — HTTP POST requests to a URL you provide.

Subscribing

Webhook subscriptions are managed per clinic in the Medevio application, in Menu → Propojky → Konfigurace webhooků (https://my.medevio.dev/klinika/nastaveni/propojky). Each subscription binds one event type to one endpoint URL. Ask the clinic administrator to set it up there, or contact Medevio support.

Signing is opt-in and is turned on while the subscription is being created — the administrator ticks Podepisovat požadavky (HMAC) in the Nová konfigurace dialog, and the signing secret (Podpisový klíč) is displayed there once, immediately after the subscription is created. Ask them for it then; it is never shown again and no query returns it. The checkbox is present only in the new-subscription dialog — signing currently cannot be turned on for an existing subscription, turned off, or the secret rotated.

Delivery format

Every delivery is an HTTP POST to the subscribed URL with Content-Type: application/json and a common envelope:

{
  "event": "<event key>",
  "clinicId": "<clinic UUID>",
  "timestamp": "<ISO 8601 time the event was emitted>",
  "data": { "…event-specific payload…" }
}

The data shape of each event is documented on its own page. Requests are sent with User-Agent: Medevio-Webhook/1.0.

Responding

Respond with any 2xx status code within 30 seconds to acknowledge the delivery. The response body is ignored.

Retries

Failed deliveries (network errors, timeouts, 5xx, and 429 responses) are retried with exponential backoff (2 s, 4 s, 8 s, 16 s between attempts), up to 5 delivery attempts in total. Other 4xx responses are treated as permanent failures and are not retried. Deliveries may occasionally arrive more than once or out of order — make your handler idempotent, e.g. by deduplicating on the envelope (event, timestamp, entity ids in data).

Verifying signatures

When signing is enabled for a subscription, every delivery carries an X-Medevio-Signature header containing the lowercase hex HMAC-SHA256 digest of the raw request body, keyed with the subscription's signing secret — the value the clinic administrator was shown once when creating the subscription (see Subscribing above). Verify it by computing the digest over the exact received bytes (do not re-serialize the JSON) and comparing with a constant-time comparison:

const crypto = require('crypto')

const expected = crypto.createHmac('sha256', signingSecret).update(rawBody).digest('hex')
const valid = crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signatureHeader))

Deliveries without signing enabled do not carry the header.

Testing

A subscription can be tested from the Medevio application; the test sends a webhook_test delivery (documented on its own page) to the subscribed URL.

Client Libraries

Webhooks (Collapsed)

​
Webhook

Patient request created

​

Fired when a new patient request is created, either by the patient or by the clinic.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientRequestCreated event

    Properties: 7
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientRequestCreated
{
  "event": "PatientRequestCreated",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientRequestId": "",
    "patientId": "",
    "createdBy": "",
    "createdByDoctor": true,
    "type": "",
    "priority": 1,
    "createdAt": ""
  }
}
No Body
Webhook

Patient request reservation changed

​

Fired when a reservation of a patient request is created or moved to a different time by the clinic.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientRequestReservationChanged event

    Properties: 9
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientRequestReservationChanged
{
  "event": "PatientRequestReservationChanged",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientRequestId": "",
    "patientId": "",
    "reservationId": "",
    "changeType": "reservationChangedByDoctor",
    "reservationStart": "",
    "reservationEnd": "",
    "originalStart": "",
    "changedBy": "",
    "changedAt": ""
  }
}
No Body
Webhook

Patient request reservation canceled

​

Fired when a reservation of a patient request is canceled, either by the clinic or by the patient. Use data.changeType to tell the two apart.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientRequestReservationCanceled event

    Properties: 9
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientRequestReservationCanceled
{
  "event": "PatientRequestReservationCanceled",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientRequestId": "",
    "patientId": "",
    "reservationId": "",
    "changeType": "reservationCancelledByDoctor",
    "reservationStart": "",
    "reservationEnd": "",
    "originalStart": null,
    "changedBy": "",
    "changedAt": ""
  }
}
No Body
Webhook

Patient request reservation reminder

​

Fired when a reservation enters its reminder window — the lead time configured per reservation (remindDaysBefore). Independent of Medevio’s own SMS/push reminders: it fires even when the patient has no reachable Medevio contact, so your system can deliver the reminder through its own channel.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientRequestReservationReminder event

    Properties: 5
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientRequestReservationReminder
{
  "event": "PatientRequestReservationReminder",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientRequestId": "",
    "patientId": "",
    "reservationId": "",
    "reservationStart": "",
    "reservationEnd": ""
  }
}
No Body
Webhook

Patient request done

​

Fired when a patient request is marked as done by the clinic.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientRequestDone event

    Properties: 1
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientRequestDone
{
  "event": "PatientRequestDone",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientRequestId": ""
  }
}
No Body
Webhook

Patient linked to user

​

Fired when a patient record in the clinic is linked to a Medevio user account — the patient accepted an invitation, including the case where the acceptance merges the invited record into an already linked patient. The payload intentionally carries no personal data; correlate via patientId or externalId.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientLinkedToUser event

    Properties: 2
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientLinkedToUser
{
  "event": "PatientLinkedToUser",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientId": "",
    "externalId": null
  }
}
No Body
Webhook

Patient tag changed

​

Fired whenever a patient tag is actually added to or removed from a patient — manual changes in the clinic, tags applied by document-signing rules, default tags of a request, patient imports and patient merges alike. Re-assigning a tag the patient already has emits nothing. Tags of patient requests are out of scope. An organization-wide tag emits one event per clinic of the organization, identical except for clinicId; deduplicate on patientId + tagId + action + changedAt. Deleting the tag definition itself does not emit removals — end a tag on a patient by unassigning it, not by deleting the tag. The payload intentionally carries no personal data; fetch the patient detail via patientId.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the PatientTagChanged event

    Properties: 7
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postPatientTagChanged
{
  "event": "PatientTagChanged",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "patientId": "",
    "externalId": null,
    "tagId": "",
    "tagName": "",
    "action": "assigned",
    "changedBy": "",
    "changedAt": ""
  }
}
No Body
Webhook

Test delivery

​

Sent when a clinic tests a webhook subscription from the Medevio application.

Body

required
application/json

Webhook delivery envelope

  • UUID of the clinic the event belongs to

  • Payload of the webhook_test delivery

    Properties: 3
  • Event key identifying the webhook type

  • When the event was emitted (ISO 8601)

Responses

  • Return any 2xx status code to acknowledge the delivery. The response body is ignored.

Request Example for postwebhook_test
{
  "event": "webhook_test",
  "clinicId": "",
  "timestamp": "",
  "data": {
    "test": true,
    "message": "",
    "webhookKey": "PatientRequestCreated"
  }
}
No Body