Lead Dispositions
Reference for the lead_dispositions resource. Requests follow the conventions in
Requests and Responses; fields you
receive and may write are filtered by your user's permissions, so responses can
contain a subset of the fields below.
Operations
| Operation | Request |
|---|---|
| List | GET /{profile}/user/v4/lead_dispositions |
| Fetch | GET /{profile}/user/v4/lead_dispositions/{id} |
Not available as a standard REST operation for this resource: create, update, delete —
such requests return 402 feature_not_enabled or 403 permission_denied.
Fields
Fields are grouped by the permission that gates them. A group you may not view
is absent from responses; a group you may not write is rejected with 422 when
sent in a write.
Lead Disposition
View: Customer Sale Info.
| Field | Type | Writable | Validation |
|---|---|---|---|
name |
string (nullable) | Read-only | max length 255 |
active |
boolean (nullable) | Read-only | — |
status |
string (nullable) | Read-only | one of: active, deleted |
Pagination
The list endpoint uses client-controlled offset pagination: ?page= (1-based) and
?per_page= (default 25, max 100). The response mirrors
meta.pagination (page, per_page, total, last_page) and sends an RFC5988
Link header; follow rel="next" to walk pages. See
Pagination.
Filters
The list endpoint accepts these query-param filters: name.
An unsupported filter parameter returns 422. See
Filtering collections
for matching semantics.
Sorting
GET .../lead_dispositions?sort= orders the list by: id, name.
Prefix a field with - for descending; comma-separate for tie-breakers. An
unsupported field returns 422. See
Sorting collections.
Related
- Requests and Responses — envelope, errors, pagination, and rate limits.
- Authentication — tokens and the
Authorizationheader.