One place to run your coaching practice

The distinction that decides how you set this up

Events here come in two kinds, and they are reached differently. If you miss this, you will look for a subscription that does not exist and conclude the feature is broken.

Emitted events happen at a definite moment

A check-in is submitted. A client is created. There is an instant when it is true, and it is the same instant for everybody. You will subscribe an endpoint to these directly, with no automation involved.

Event	Fires when
`new_client`	A client was created, by anyone — the app, an import, or the Partner API.
`check_in_submitted`	A client submitted a check-in.
`low_check_in_score`	A check-in answer fell below the threshold your automation sets.
`system_grade_drop`	A wellness system grade fell compared with the previous check-in.
`phase_advanced`	A client moved to a new programme phase.
`message_received`	A client sent a message.

Computed events only exist because you defined them

“Compliance dropped” is not a moment — it is a judgement against a threshold you chose, about an audience you chose. There is no universal instant at which it becomes true, so there is nothing to subscribe to. These are found by a periodic sweep against the rules in your automations.

Event	Fires when
`compliance_drop`	Compliance fell below the threshold your automation sets.
`compliance_milestone`	Compliance reached the milestone your automation sets.
`phase_eligible`	A client became eligible to advance a phase.
`check_in_inactivity`	A client has not checked in for as long as your automation allows.
`daily_log_inactivity`	A client has not logged a day for as long as your automation allows.

You will reach these by building an automation with that trigger and adding a Webhookstep to it. In our builder it is an action; on your platform the POST it makes is a trigger. That is also why the payload carries the automation’s id and threshold — running two compliance automations at different thresholds would otherwise give you two identical-looking deliveries with no way to tell which rule fired.

What a delivery looks like

POST https://your-system.example.com/hooks/launchsite
Content-Type: application/json
webhook-id: msg_2b3c4d…
webhook-timestamp: 1755360000
webhook-signature: v1,K5oXf8…
x-launchsite-event: compliance_drop

{
  "type": "compliance_drop",
  "timestamp": "2026-08-17T09:15:00.000Z",
  "data": {
    "client": { "id": "…" },
    "compliance_pct": 61,
    "automation": { "id": "…", "name": "Chase low compliance", "threshold": 65 }
  }
}

You choose what an endpoint carries

This is set when you create the endpoint, and it is a real choice rather than a default to leave alone.

Mode	What arrives
Identifiers only	Ids, figures, dates and the automation context. Nothing that names a person. You look the client up over the Partner API with a key that is scoped and revocable.
Include contact details	The above, plus name, email address and phone number.

Pick deliberately. Identifiers only is the tighter option, but GoHighLevel, Zapier and Make all match their own contact records on email or phone — handed only our client id, their workflow finds nothing and reports no error anywhere you would look. If that is your destination, you almost certainly want contact details.

Some things are never sent in either mode, and no setting reaches them: check-in answers and any free text a client wrote, wellness system grades, lab results, progress photographs, and message content. When you need those, fetch them with an API key.

What your endpoint must do

Be HTTPS, and publicly reachable. We refuse plain HTTP, and we refuse to resolve to a private or internal address.
Verify the signature before acting. See Verify a signature. An unverified endpoint will act on anything anyone posts to it.
Answer 2xx quickly. Anything else is treated as a failure and retried. Do the work after you have replied, not before.
Deduplicate on webhook-id. It identifies the event and is stable across retries, so it is exactly the key to store. Deliveries are not ordered — a retried event can arrive after a newer one that succeeded first.
Do not follow up with a redirect. We will not follow one; point the endpoint at its final URL.

When your endpoint is down

We retry eight times over roughly 27 hours, with the early gaps short — most failures are a receiver restarting — and the later ones long, because something still down after two hours is not coming back in five minutes.

Return 410 Gone and we stop immediately and permanently. That is the polite way to retire an endpoint you no longer own. An endpoint that keeps failing across a multi-day window is disabled automatically, and you will be able to see why in its delivery log.