CRM Integration

This page exists to answer one question honestly and in one screen: can you connect Leed to your CRM? The short answer is that there is a single inbound webhook a Salesforce org can call, that what happens to the events it delivers is written per customer, and that there is no integrations panel anywhere in the product. Read this before you go looking in Settings for a switch.

What exists today

One HTTP endpoint. A Salesforce org calls it when a record changes; Leed authenticates the call with a Leed API token, resolves that token to the workspace it belongs to, and queues the change for processing. That is the whole integration surface — one direction, one CRM, one endpoint.

The endpoint sits at a fixed path that is handed to you during onboarding rather than published here. It is Bearer-authenticated and rejects any token it does not recognize, any token that has been disabled, and any token that has expired, all with a 401. A body it cannot parse is refused with a 406. Nothing about the endpoint is usable without the workspace-side work described below, so knowing the path would not get you further.

sequenceDiagram
    autonumber
    participant SF as Your Salesforce org
    participant NM as Leed webhook endpoint
    participant Q as CRM event queue
    participant CP as CRM processor
    participant L as Your Leed workspace
    SF->>NM: POST change notification<br/>Authorization: Bearer API-token
    NM->>NM: Resolve token → user → organisation → workspace
    alt Token unknown, disabled or expired
        NM-->>SF: 401
    else Body does not match the expected shape
        NM-->>SF: 406
    else Authorised
        NM->>Q: Queue the workspace, source and change notification
        NM-->>SF: 200
    end
    Q->>CP: Deliver the event
    alt A handler is registered for this workspace
        CP->>SF: Read the full record back out of Salesforce
        CP->>L: Apply that workspace's mapping
    else No handler for this workspace
        CP--xCP: Event is not accepted
    end

The diagram makes the two real limits visible. The payload is a pointer, not a record. And the processor only acts on events for a workspace that has a handler written for it.

What the webhook actually carries

A change notification, not the changed record. Three fields:

{
  "Id": "0015g00000XyZaBAAV",
  "Type": "Account",
  "LastModifiedDate": "2026-09-02T14:31:07.000Z"
}

Type is one of Account, Contact, User or Lead. Anything else is rejected. Nothing in the payload says what changed, and no field values travel with it — a handler that wants the record reads it back out of Salesforce using your org’s own credentials. That design keeps field-level data out of the queue, and it also means the integration cannot work without authenticated read access back into your Salesforce org, which is part of what onboarding sets up.

Handling is written per workspace

The processor keeps a registry of handlers keyed by workspace. When an event arrives it looks up the workspace, and if no handler is registered the event is simply not accepted — no error reaches your CRM, because the webhook has already returned 200 by then, and nothing appears in Leed.

That is the honest reason CRM integration is an onboarding conversation and not a feature toggle: the mapping between your CRM objects and Leed’s contact and account records is code, written for your workspace. What you keep in a Salesforce custom field, which objects you care about, and which direction the truth flows are all decisions that become part of that handler.

How CRM data appears in Engage

Contacts and accounts carry a Source field, and salesforce is one of its values — it means the record arrived through this path rather than from a form, an import or the API. Once it lands, a Salesforce-sourced contact is an ordinary contact: it appears in the contact list, it can be edited, it can be added to a group, and it is scored by the same recompute as everything else. There is nothing CRM-specific about it downstream. Contacts describes the record itself, and Accounts the business behind it.

The one part you can do yourself

Creating the API token the webhook authenticates with is self-serve, and it is the only piece of this that is. It lives on your own profile’s security screen, not in workspace Settings.

The shipped copy states the intent plainly: “API tokens are used for service-to-service integrations (e.g., Salesforce webhooks, CI pipelines). The token value is shown only once at creation.” Three things to know before you create one:

• A name and an expiration are both required. The expiration dropdown offers 30, 60 or 90 days, 6 months, 1 year, or no expiration; the form will not submit until you pick one.
• The value is shown once. Copy it when it is created — the panel says “Token created — copy it now, it won’t be shown again” — and store it in whatever your Salesforce side uses for secrets. There is no way to read it back.
• A token resolves to a workspace through its owner. The webhook maps the token to the user who created it, then to that user’s organization, then to the Leed workspace. Create the token as the identity that should own the integration.

Managing, revoking and auditing tokens is covered in Sessions, Connected Accounts and API Tokens.

HubSpot

What does not exist

Naming the gaps is the point of this page, because every one of them is something a reader would otherwise spend an afternoon looking for.

That last row is worth separating out. Account-based qualification is sold on the same Enterprise tier and is easy to mistake for the buying-committee and readiness work you can already see on Accounts. It is not the same thing, and it has not shipped. It sits alongside CRM integration in What Leed Does Not Do.

If you need this

Talk to sales. The integration is scoped and built per workspace, so the conversation is a technical one from the start, and it goes faster if you arrive with three answers:

1. Which objects. Accounts, Contacts, Leads, Users — and which of them should create or update records in Leed.
2. Which direction. Today the mechanism only carries changes into Leed. If you need Leed’s engagement data flowing back into your CRM, say so early; that is new work, not configuration.
3. Which fields. Which Salesforce fields, including custom ones, map onto which parts of a Leed contact or account — and which side wins when both have a value.

Contacts arriving from a CRM are one of six ways a person ends up in your workspace; the rest, and the shape of the record they land in, are on Contacts, reached from Engage Workspace.