ConceptsFields and custom fields
Fields and custom fields
Read an entity's fields and dropdown options from the Fields endpoint, create custom fields, and update dropdown options without deleting the ones you leave out.
Answer
GET /entities/Fields with filter[entity_name]=Account lists an entity's fields with their api_name, type and options. Create a custom field with POST /entities/Fields and change it with PATCH /entities/Fields/{id}. A data_set you send replaces the whole option list: an option you leave out is deleted. Key integrations on api_name, never on the label.
Fields are records too. The Fields entity describes every field of every entity in your space,
the standard ones and your custom ones, so an integration can find a field's API name and its
dropdown options at run time instead of hard-coding them.
Find a field's API name
List an entity's fields with GET /entities/Fields and these parameters:
| Parameter | Value | Why |
|---|---|---|
filter[entity_ |
Account |
The singular entity name, such as Account, Opportunity, OpptyProductRelation or Quote. The shared parents LeadOppty and Activity have no fields of their own: ask for Lead or Opportunity, Task or Appointment. |
expand |
data_ |
Returns a dropdown's options with their id and option_ |
load-only |
id,name,api_ |
Keeps the response small |
first |
100 |
An entity can have more fields than the default page of 30 |
Each field has a name, the label the app shows, and an api_name, the key in the entity's
records. Custom fields have API names that start with cf_; a dropdown's ends with _id, because
the record stores the option's ID.
The API name is made from the field's name when the field is created, and then it stays:
- Renaming a field changes
name, notapi_name. - A field deleted and created again under the same name gets a new API name with a number added:
cf_customer_tierbecomescf_customer_tier1. An integration keyed on the old name stops finding the field.
So store api_name, never the label, and do not recreate a field an integration uses.
Create a custom field
POST /entities/Fields creates a field. The body names the entity
in entity_name, the label in name and the type in type_id:
type_ |
Field |
|---|---|
input, text_ |
Single-line and long text |
integer, float, currency, currency_ |
Numbers and money |
date, datetime |
A date, a date and time |
checkbox |
True or false |
dropdown, radio, multiselect_ |
Options from data_: an array of { "option_ |
email, phone, url |
Validated text |
sequence |
An auto-number |
Give every option a calc_value, the number it counts as in calculated fields.
Update dropdown options
Update a field with PATCH /entities/Fields/{id}. A PATCH sent to /entities/{id} without
Fields in the path answers HTTP 405.
data_set replaces every option
The data_set you send becomes the field's whole option list. Send every option you keep, each
existing one with its id, and new ones without an id. An option you leave out is deleted.
For example, a dropdown with the options Gold, Silver and Bronze, updated with a data_set of
Gold (by its id) and a new Platinum, reads back with expand=data_set as Gold and Platinum:
Silver and Bronze are deleted.
Limits
| Limit | Details |
|---|---|
entity_ |
Concrete entities only; LeadOppty and Activity have no fields |
data_ |
Replaces the whole list on every write |
| API names | Fixed at creation; a re-created field gets a new one |
| GraphQL | This page covers REST; the public GraphQL schema has its own field repository |