Developers
Set your API contextPick a region and space ID once. Every sample fills in your base URL.
Where do I find these?

In Coevera: open your space's API application and choose Show Access. It shows the space ID and the base URL, whose host starts with your region.

From the API: if you know the space ID, the discovery endpoint GET /api/discovery/spaces/{space_id} returns its region and base URLs, without credentials.

Only the region and space ID are kept, in this browser. Never paste a key or password here.

More in the quickstart

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_name] 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_set Returns a dropdown's options with their id and option_name
load-only id,name,api_name,type_id,data_set.id,data_set.option_name 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, not api_name.
  • A field deleted and created again under the same name gets a new API name with a number added: cf_customer_tier becomes cf_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_id Field
input, text_area Single-line and long text
integer, float, currency, currency_foreign Numbers and money
date, datetime A date, a date and time
checkbox True or false
dropdown, radio, multiselect_checkbox Options from data_set: an array of { "option_name", "calc_value" }
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_name Concrete entities only; LeadOppty and Activity have no fields
data_set 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