API Changelog
Custom field values on Contacts and Matters
Release Date: 2026-08-25
Summary Of Changes
Opt in to custom field values with the include parameter
The Contacts and Matters endpoints now accept an include query parameter that expands related resources in the response. Pass include=custom_field_values to add each record's custom field values to the payload. It is supported on both the list and show operations of each resource: GET /contacts, GET /contacts/{id}, GET /matters, and GET /matters/{id}.
| Parameter | Type | Description |
|---|---|---|
include | string | Comma-separated list of related resources to expand in the response. Omitted resources are absent from the payload rather than null, and unrecognized values are ignored. Currently the only supported value is custom_field_values, which additionally requires the custom_field_read scope. |
Custom field values are off by default — the custom_field_values array is absent from responses unless include=custom_field_values is supplied. This keeps existing Contact and Matter responses unchanged for integrations that do not opt in.
New custom_field_values array on Contact and Matter responses
When requested, each Contact and Matter is serialized with a custom_field_values array. Each element has the following fields:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the custom field value. |
global_id | string | Global ULID identifier for the value. |
clio_id | string | Clio Manage identifier if the value was synced from Clio Manage; null otherwise. A string (e.g. text_line-4567), unlike clio_id elsewhere in this API, because Clio Manage identifies a value by its type and its per-type row. |
field_name | string | The name of the custom field this value belongs to. null when the field's definition is missing. |
field_type | string | The type of the custom field, using Clio Manage terminology. null when the definition is missing. One of checkbox, contact, currency, date, email, numeric, picklist, text_area, text_line, url. |
value | string, number, or boolean | The value coerced to the type named by field_type: a boolean for checkbox, an ISO-8601 date for date, a number for numeric and currency, and a string otherwise. null when the stored text cannot be coerced — raw_value still carries it. |
raw_value | string | The value before coercion, exactly as stored. Identical to value for types that need no coercion, and the only place the original survives when coercion fails. |
custom_field | object | The custom field definition this value belongs to (see below). null when the definition is missing. |
picklist_option | object | The selected option. Present only when field_type is picklist, and null when the stored value matches none of the field's options. |
created_at | datetime | Timestamp when the value was created (ISO-8601). |
updated_at | datetime | Timestamp when the value was last updated (ISO-8601). |
The nested custom_field definition is serialized with:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the custom field. |
global_id | string | Global ULID identifier for the custom field. |
clio_id | integer | Clio Manage identifier if synced; null otherwise. |
name | string | The name of the custom field. null when the definition is missing. |
field_type | string | The type of the custom field (same enumeration as above). null when the definition is missing. |
parent_type | string | The kind of record this custom field applies to. One of Contact or Matter. |
displayed | boolean | Whether the field is applied to newly created records of its parent type. |
deleted | boolean | Whether the custom field's definition has been deleted. Values belonging to a deleted definition are not returned. |
picklist_options | array | The options available on a picklist custom field, in display order. Present only when field_type is picklist. |
created_at | datetime | Timestamp when the custom field was created (ISO-8601). |
updated_at | datetime | Timestamp when the custom field was last updated (ISO-8601). |
Each picklist_option (on custom_field_value.picklist_option and custom_field.picklist_options) is serialized with:
| Field | Type | Description |
|---|---|---|
global_id | string | Global ULID identifier for the option. null for options synced from Clio Manage before global identifiers were issued. |
clio_id | integer | Clio Manage identifier for the option. null for options created in Clio Grow. |
option | string | The option's label. |
An option carries no identifier of its own in Clio Grow, so it is identified by global_id, by clio_id, or by both: an option created in Clio Grow has a global_id and no clio_id, and an option synced from Clio Manage before global identifiers were issued has the reverse.
Field types use Clio Manage terminology
field_type reports Clio Manage's type names rather than Clio Grow's internal names. Six differ: Clio Grow's dropdown, single_line_text, paragraph_text, contact_select, integer, and money are published as picklist, text_line, text_area, contact, numeric, and currency respectively.
Access is gated by the custom_field_read scope
Reading custom field values requires the custom_field_read OAuth scope. If the token lacks this scope, the request still succeeds with a 200 — the custom_field_values array is returned as null and custom_field_values is listed in the record's redacted_fields, rather than returning a 403. An empty array ([]) means the record genuinely has no values, so a caller can distinguish "redacted" from "none".
Known limitations
- A
contact(contact-select) value reports the contact's name invalueonly. Clio Grow does not store a reference to the contact record, so there is no nested contact object to resolve. - There is no Clio Manage-style
fields=projection selector for choosing which custom field attributes are returned.
See the API Reference for List contacts, Get a contact, List matters, and Get a matter for more information.
Matter Types and Locations endpoints, and matter type / office location support for Inbox Leads
Release Date: 2026-08-25
Summary Of Changes
New Matter Types endpoints
We have introduced a new Matter Types resource, which represents a matter type on the account. The following endpoints are now available:
| Endpoint | HTTP Methods |
|---|---|
/matter_types | GET/POST |
/matter_types/{id} | GET |
GET /matter_types returns a paginated list of the account's matter types and supports the standard page_token, created_since, updated_since, and ids[] query parameters. POST /matter_types creates a new matter type from a data.name value; name is required, has a maximum length of 255 characters, and must be unique per account — a request with a duplicate or missing name returns a 422 error. GET /matter_types/{id} returns a single matter type.
Each matter type is serialized with the following fields:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the matter type. |
name | string | The name of the matter type. |
default | boolean | Whether this is the account's default matter type. Matters created without an explicit matter type fall back to it. Read-only; it cannot be set through the API. |
created_at | datetime | Timestamp when the matter type was created (ISO-8601). |
updated_at | datetime | Timestamp when the matter type was last updated (ISO-8601). |
Reading matter types requires the matter_type_read OAuth scope, and creating a matter type requires the matter_type_write scope.
See the API Reference for List matter types, Create a matter type, and Get a matter type for more information.
New Locations endpoints
We have introduced a new Locations resource, which represents an office location on the account. The following endpoints are now available:
| Endpoint | HTTP Methods |
|---|---|
/locations | GET/POST |
/locations/{id} | GET |
GET /locations returns a paginated list of the account's locations and supports the standard page_token, created_since, updated_since, and ids[] query parameters. POST /locations creates a new location from a data.name value; name is required, has a maximum length of 255 characters, and must be unique per account (case-insensitive) — a request with a duplicate or missing name returns a 422 error. GET /locations/{id} returns a single location.
Each location is serialized with the following fields:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the location. |
name | string | The name of the location. |
created_at | datetime | Timestamp when the location was created (ISO-8601). |
updated_at | datetime | Timestamp when the location was last updated (ISO-8601). |
Reading locations requires the location_read OAuth scope, and creating a location requires the location_write scope.
See the API Reference for List locations, Create a location, and Get a location for more information.
Inbox Leads now support a matter type and office location
We have added matter_type and matter_location fields to the Inbox Leads endpoints so that a lead can be associated with one of the account's matter types and one of its office locations.
On create, POST /inbox_leads now accepts optional matter_type and matter_location objects that reference the matter type and location to attach to the lead:
| Field | Type | Description |
|---|---|---|
matter_type.id | integer | The ID of the matter type to associate with the lead. |
matter_location.id | integer | The ID of the location to associate with the lead. |
Both are best-effort: if the supplied id does not resolve to a matter type or location on the account, it is ignored and the lead is still created.
The matter_type and matter_location objects are also returned on the Inbox Lead responses (create, list, and get). Each is null when no matter type or location is attached to the lead:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the matter type or location. |
name | string | The name of the matter type or location. |
POST /inbox_leads continues to require only the lead_inbox_write scope — referencing a matter type or location on a lead does not require the matter_type_read or location_read scopes. Existing integrations are unaffected: matter_type and matter_location are optional on create, and responses return null for leads that have no associated matter type or location.
See the API Reference for the Inbox Leads endpoints for more information.
Lead Sources endpoints and marketing source support for Inbox Leads
Release Date: 2026-08-19
Summary Of Changes
New Sources endpoints for managing lead sources
We have introduced a new Sources resource, which represents a lead source (marketing source) on the account. Two new endpoints are now available:
| Endpoint | HTTP Methods |
|---|---|
| /sources | GET/POST |
GET /sources returns a paginated list of the account's lead sources and supports the standard page_token, created_since, updated_since, and ids[] query parameters. POST /sources creates a new lead source from a data.name value. The name is required, has a maximum length of 255 characters, and must be unique per account (case-insensitive); a request with a duplicate or missing name will return a 422 error.
Each source is serialized with the following fields:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the source. |
name | string | The name of the lead source. |
category | string | The category of the source. One of standard or clio_email_marketing. |
is_editable | boolean | Whether the source can be modified by the firm. |
created_at | datetime | Timestamp when the source was created (ISO-8601). |
updated_at | datetime | Timestamp when the source was last updated (ISO-8601). |
See the API Reference for List lead sources and Create a lead source for more information.
Inbox Leads now support an associated marketing source
We have added a marketing_source field to the Inbox Leads endpoints so that a lead can be associated with one of the account's lead sources.
On create, POST /inbox_leads now accepts an optional marketing_source object that references the Grow Source to attach to the lead:
| Field | Type | Description |
|---|---|---|
id | integer | The ID of the Grow Source to associate with the lead. |
The marketing_source object is now also returned on the Inbox Lead responses (create, list, and get). It is null when no source is attached to the lead:
| Field | Type | Description |
|---|---|---|
id | integer | Unique identifier for the marketing source. |
name | string | The name of the marketing source. |
Existing integrations are unaffected — marketing_source is optional on create, and responses return null for leads that have no associated source. We recommend updating your integration to handle the presence of the marketing_source field in Inbox Lead responses.
See the API Reference for the Inbox Leads endpoints for more information.