# Configure webhooks in Studio
URL: https://docs.awellhealth.com/docs/automate-with-events/configure-webhooks-in-studio

> For the complete documentation index, see [llms.txt](https://docs.awellhealth.com/llms.txt).





Webhooks let a care flow tell another system what happened. This page covers switching them on in the
care flow's settings; someone technical has to build the receiving end first.

## The URL and the public key change hands first [#the-url-and-the-public-key-change-hands-first]

The team receiving the events supplies **the URL** to send them to. They need **Awell's public key**
back, so they can prove each message really came from Awell.

## Add a webhook to a care flow [#add-a-webhook-to-a-care-flow]

1. Open the care flow.
2. Go to its **Settings**, then **Webhooks**.
3. Add a webhook: give it a name, paste the URL, and choose which events to send.
4. Save.

Choose events deliberately. Sending everything leaves the other system to work out what matters, and
makes problems harder to spot.

## The public key belongs to your organization, not to one webhook [#the-public-key-belongs-to-your-organization-not-to-one-webhook]

Awell signs every outgoing webhook with a private key held for your organization, and the receiving
end verifies it with the matching **public key**. There is no per-webhook secret to copy: the same
key verifies every outgoing webhook, however it was set up.

Get it from **Integrations → Outgoing webhooks → Public key**, which shows it as a PEM block.

**It is a public key, so it is not a secret.** It can go in a config file, a repository, or a ticket
like any other public key. Nothing is weakened by someone else seeing it — only the private key,
which never leaves Awell, could let anyone forge a signature.

See [Receive webhook events](/docs/automate-with-events/receive-webhook-events) for the verification
itself.

## Disabling is a pause, not a queue [#disabling-is-a-pause-not-a-queue]

A webhook can be disabled without being deleted while the receiving system is down for maintenance or
being changed: the configuration stays and the traffic stops.

Events that happen while a webhook is disabled are not sent.

## Check whether a call arrived [#check-whether-a-call-arrived]

Configuration and logs live in different places, which is the part most people get wrong.

* **Integrations** is where webhooks are set up: it has an **Incoming webhooks** tab and an
  **Outgoing webhooks** tab.
* **Monitor** is where the traffic is inspected, with **Outgoing Webhooks** and **Incoming Webhooks**
  each listed under it.

Each call shows whether it succeeded. Filter by care flow name, care flow ID, webhook ID, patient ID,
or by status, to look at just the failures.

<img alt="The webhook log, listing each call with its patient, care flow, time and response code, with a Retry action on every row" src="__img0" />

Logs are kept for roughly **five days**, and up to **1,000 calls** — the log itself states both limits.

## Retry something that failed [#retry-something-that-failed]

Once the receiving system is back up, resend a webhook call one at a time, or resend all the failed
calls for a care flow at once.

Awell also retries automatically when a call fails, waiting longer between each attempt. It starts at a
couple of seconds and backs off for up to about **18 hours** before it stops trying, so a brief outage
usually resolves without a manual retry.

## Next steps [#next-steps]

* **Something isn't arriving?** Check the logs above first, then confirm the URL and the events with
  the receiving engineer.
* **What's actually being sent?** →
  [Webhooks and events](/docs/automate-with-events/webhooks-and-events)
* **Traffic the other way, with another system starting a care flow?** →
  [Start a care flow from an incoming webhook](/docs/automate-with-events/start-a-care-flow-from-an-incoming-webhook)