Leads
The lead object and the endpoints that work with it.
A lead is a prospective client captured from any source: a web form, an ad, a referral, an imported list, or the push endpoint.
Endpoints
| Method | Path | Scope | Description |
|---|---|---|---|
GET | /api/leads | leads:read | List leads (filtered, paginated) |
GET | /api/leads/{id} | leads:read | Fetch a single lead |
POST | /api/leads | leads:write | Create a lead |
PATCH | /api/leads/{id} | leads:write | Update a lead (partial) |
POST | /api/leads/{id}/archive | leads:write | Archive a lead |
POST | /api/leads/{id}/unarchive | leads:write | Restore a lead |
The lead object
{
"id": "3f8c1e2a-1b2c-4d5e-8f90-abcdef012345",
"first_name": "Ada",
"last_name": "Lovelace",
"email": "ada@example.com",
"phone": "+15551234567",
"source": "web_form",
"status": { "key": "new", "name": "New" },
"assignee_id": null,
"archived": false,
"created_at": "2026-06-23T10:00:00.000Z",
"last_activity_at": "2026-06-23T10:00:00.000Z",
"data": { "city": "London", "qualification": "qualified" }
}| Field | Type | Notes |
|---|---|---|
id | string | UUID, stable. |
first_name, last_name | string | |
email | string | Lowercased. |
phone | string | Normalized to E.164 where possible. |
source | string | Where the lead came from (e.g. web_form, zapier). |
status | object | The firm's pipeline stage: a stable key and a display name. |
assignee_id | string | null | The assigned staff member's id, if any. |
archived | boolean | Whether the lead is archived. |
created_at | string | ISO 8601 timestamp. |
last_activity_at | string | ISO 8601 timestamp of the most recent activity. |
data | object | The lead's contact fields, by key (varies per firm). See Fields in data. |
status.key is a stable identifier you can branch on; status.name is for display and a firm
can rename it. Filter by the key.
Fields in data
data holds the lead's contact fields, keyed by each field's key. Your firm defines its fields in Settings → Contact fields
(a field's key is made from the name it was first given and never changes). When you
create or update a lead, each key is handled one of three ways.
The default keys keep this API version's rules, whatever kind the firm's field now has: caseType, hierarchy,
preferredLanguage, countryOfOrigin, city, state, zip, gender, dob, referralSource and message.
caseType and hierarchy must be one of the firm's case types or hierarchies (a 422, for example "Invalid case
type."); the others are stored as trimmed text. A value that isn't text, or is blank, is ignored. Stricter checks
for these keys will come with a new dated API version.
qualification and contactType are lists the app manages. A text value must be one of the firm's
qualifications or contact types (a 422: "Invalid qualification." or "Invalid contact type."); a value that isn't
text, or is blank, is ignored.
Every other field your firm defines is checked by its kind, with the app's own rules:
- Short text, long text, choice, country, language and US state take text; a date takes text as
YYYY-MM-DD; a number takes a number or its digits as text (42or"42"); yes or no takestrueorfalse, or the text"Yes"or"No"; multiple choice takes an array of option labels (at most 100). - A choice must be one of the options your firm has defined. A date must be real, from 1900 to 2199. Text is at most 20,000 characters.
- An invalid value is a
422 invalid_requestwhosemessagenames the key, for example "data.passportNumber must be text." or "data.visaStatus must be one of your firm's visa status options." nullor a blank value is ignored: the API doesn't clear a field.
The default keys are stored even when your firm has retired their field. Any other key (an unknown key, or a field your firm added and then retired) is ignored and isn't stored.
Reads return everything stored in data, including keys a lead source sent and fields your firm has since retired.