Leads & App Integrations
Your leads do not have to live only inside the admin portal. When you have an app installed on your site — for example a CRM connector, an email-marketing integration, or an internal notification tool — SitePack can automatically tell that app whenever something happens to a lead. This lets you sync new enquiries into another system, trigger an automated follow-up, or post a message to your team the moment a lead comes in, without anyone having to copy details across by hand.
This happens through webhooks. The rest of this page explains how they work. It is more technical than the Lead Management guide — you do not need any of it to use the Leads section day to day, but it is useful if you (or a developer working with you) want to connect leads to another tool.
What is a webhook?
A webhook is an automatic message that SitePack sends to another system when an event happens. Instead of the other system constantly asking "any new leads yet?", SitePack proactively pings it the instant a lead is created or changes. The message is a standard HTTP POST request with a small JSON body, delivered to a web address (endpoint) that the app defines.
You never configure these addresses yourself in the Leads section — an app declares which lead events it wants to listen to when it is built and installed. As a site owner, you simply install the app, and the relevant lead events start flowing to it.
For privacy, a lead webhook contains only the lead's identifier (uuid) — never a name, email, or any other personal detail. It is a notification that says "this lead changed," not a copy of the lead. When an app needs the actual details, it uses the uuid to fetch the current lead through the API. This keeps personal data out of webhook traffic and means the app always reads the latest state rather than a stale snapshot.
The lead events
SitePack fires three lead-related events. An app only receives the ones it has subscribed to.
| Event | When it fires |
|---|---|
lead.created | A brand-new lead is captured (a new contact-form submission, newsletter signup, or product request). |
lead.updated | An existing lead changes — its status is changed, its rating is overridden, a note is added, or a repeat enquiry is merged into it. |
lead.completed | A lead is closed, either as Completed (deal) or Completed (no deal). This fires in addition to a lead.updated event for the same change. |
Closing a lead produces two notifications: first a lead.updated, then a lead.completed. An integration that only cares about won or lost deals can listen for lead.completed alone and ignore the general lead.updated stream.
What a webhook message looks like
Every webhook is delivered as an HTTP POST with a small JSON body in the following shape:
{
"uuid": "0192f0c3-1a2b-7c3d-8e4f-5a6b7c8d9e0f",
"test_mode": false,
"topic": "lead.created",
"site": "a1b2c3d4-....-site-uuid",
"created_at": "2026-07-13T10:15:42Z",
"arguments": {
"uuid": "f9e8d7c6-....-lead-uuid"
}
}
The top-level fields describe the delivery itself:
uuid— a unique id for this individual webhook delivery (not the lead — seeargumentsbelow).test_mode—truewhen the message was sent as a test (for example while a developer is building the app),falsefor real, live events.topic— which event this is:lead.created,lead.updated, orlead.completed.site— the unique identifier of the site the lead belongs to.created_at— when the event happened, in UTC (ISO 8601).arguments— the event data (see below).
The lead payload (arguments)
The arguments object is intentionally minimal — it carries only the lead's identifier:
| Field | Meaning |
|---|---|
uuid | The lead's unique identifier. Use it to fetch the full, current lead through the API, and to recognise repeated events about the same lead. |
No personal data (name, email, phone, message, deal value, and so on) is ever included in the webhook itself. To act on an event, the app takes this uuid and requests the lead's current details from the API — so it always works with the latest state rather than whatever was true at the moment the webhook fired.
How delivery works
- Only to apps installed on the site. A webhook for a lead is sent to the apps activated on that lead's site, and only to those that subscribed to the matching event. If no installed app listens for lead events, nothing is sent.
- Processed in the background. Webhooks are dispatched asynchronously, so capturing or updating a lead is never slowed down or blocked by a slow or unreachable endpoint. A visitor submitting your contact form never waits on a third-party system.
- Best-effort. Lead capture is designed never to fail because of an integration — if notifying an app runs into trouble, the lead is still saved and visible in your admin portal.
For developers
If you are building an app that consumes these events, the full technical reference — how to declare webhook subscriptions in your app manifest, endpoint requirements, and testing with test_mode — lives in the developer documentation:
See also Developing Apps for how apps are built and distributed as a SitePack Partner.
Frequently asked questions
Do I need to set up webhooks to use leads?
No. Webhooks are entirely optional and only relevant if you want to connect leads to another system through an app. The Leads section works fully on its own — see Lead Management.
Which lead events can an app receive?
Three: lead.created when a lead is captured, lead.updated when it changes, and lead.completed when it is closed as a deal or no-deal. An app receives only the events it subscribed to.
How do I connect my leads to my CRM or mailing tool?
Install an app that integrates with that tool. Once installed, SitePack automatically sends the relevant lead events to it. If no app exists for your tool yet, a developer can build one using the App Documentation.
Why doesn't the webhook include the lead's name or email?
By design. Webhooks only carry the lead's uuid, never personal data — this keeps sensitive information out of webhook traffic. The app uses the uuid to fetch the current lead details from the API when it actually needs them, which also guarantees it always sees the latest state.
Will a slow integration delay my website?
No. Lead webhooks are sent in the background, separately from the visitor's action, so capturing a lead is never held up by an external system.