List custom fields
Lists your reusable custom-field definitions, cursor-paginated, with live usage bookkeeping on every row: usage_count and cards_using[] show exactly which card templates reference each field - the numbers that decide which edits are allowed (renames, type changes, and option removals are blocked while a field is in use). Scope: custom_fields:read.
Filter by field_type.
Authorizations
Your secret API key as a Bearer token: Authorization: Bearer vxn_sk_.... Keys are created and scoped in the dashboard - see Authentication.
Query Parameters
Page size, 1-100. Default 25.
1 <= x <= 100Cursor: object id from the previous page (forward walk). Numeric offset or page parameters are not supported; cursors are the only supported paging mechanism.
Cursor: object id from the previous page (reverse walk).
Filter by field type (the 8-type registry - see the Custom Field object).
text, textarea, number, currency, date, boolean, select, multiselect Response
Paginated custom field list.
Standard cursor-pagination envelope for list endpoints. See the Pagination guide.
Always "list".
"list"Array of the requested resource type.
True when more pages exist - pass the last item id as starting_after.
Cursor for the next page in the direction you are already paging, or null when this page ends the collection. has_more: true always comes with a non-null next_cursor.
Feed it back to the SAME parameter you used: starting_after when paging forward (the default), or ending_before when paging backward. Treat it as opaque and do not parse it.
You no longer need to take the last object's id yourself. That still works and is unchanged, but deriving the cursor from the page put the burden of knowing the sort direction on you, and it broke silently on any endpoint whose cursor is not the object id.
"cus_iofv5j4hn6bphinmmyat27tc5y"
Stable collection URL.
"/v1/custom_fields"