Create a lead
Adds a lead to the workspace, optionally straight into a campaign.
Leads are deduplicated across the whole workspace by the person they resolve to, so posting the same email twice returns the same lead with created: false and a 200 rather than creating a second row. That is what makes a retry safe — there is no idempotency key to manage, and it also catches the same person arriving from two different integrations.
name is required, plus at least one of email, phone or linkedinUrl: without one of those there is no way to recognise this person again. When campaignId is given, any workflow with a Lead enters campaign trigger fires, exactly as it would for a lead added in the Cockpit.
Custom fields sent on create are applied to the lead that is returned — including when that is an existing lead. Re-running an import therefore updates the values in place rather than dropping them with the duplicate, so the same migration can be run twice and converge.
Authorizations
Your API key, created in the Leadey dashboard under Settings → API Keys. Send it as Authorization: Bearer leadey_sk_live_….
Body
The person's full name.
Work email address.
Phone number in E.164 format.
Their LinkedIn profile URL.
Company name.
Job title.
Add the lead straight into this campaign.
Where the lead came from. Shows in the Cockpit and can be filtered on with GET /leads?source=. Defaults to api.
Custom field values, keyed by field key. A field that doesn't exist yet is created automatically, so a migration doesn't have to pre-declare its columns — which makes this the place to park foreign identifiers such as a record id from your previous CRM.
Keys are slugified (Legacy Record ID is stored as legacy_record_id), and the response echoes the canonical keys so you can see exactly what landed. Values are stored as text; numbers, dates and booleans are coerced.
Response
This person was already in the workspace. The existing lead is returned unchanged.