Skip to main content
Custom fields let you store your own data on RevyOps records. They’re typed: a field is defined once with a type, and every value written to it is checked against that type. Custom fields exist for contacts, companies, and custom activity types; emails have their own lighter-weight custom fields that aren’t part of this schema.

​
The five field types

available_options is capped at 50 values.

​
Configuration

​
Defining a field

GET /public/custom-fields/schema?object=contact (or company) lists every field the client can read or write. POST /public/custom-fields/schema defines a field and sets its type, so it exists on every record and in the filter schema before any value is written. Repeating the call for a field this workspace owns updates its type; setting type: "text" again does not remove it (removal isn’t exposed through this endpoint). Existing values are checked against the new type before it’s applied: a number field rejects non-numeric values, a date field rejects anything but YYYY-MM-DD, and a dropdown rejects values outside available_options. Defining or redefining a field that already has out-of-type values fails (400) and names them.

​
Agency vs. client fields

Every custom field has a source: agency or client.
  • agency: defined in the agency’s master schema, shared across every client workspace under that agency. Its type is managed at the agency level; a client-level POST /public/custom-fields/schema call against an agency-owned field is rejected with 409.
  • client: defined for one workspace only, through that workspace’s own API key or MCP session.
The agency Schema Settings page in the UI shows both agency and client fields for a client, and lets an agency promote a client field into the agency master schema.

​
Writing values

Once a field is defined, values are written per record:
  • POST /public/contacts/{contact_id}/custom-fields and PATCH .../custom-fields/{field_id} set or update a contact’s value for a field.
  • POST /public/companies/{company_id}/custom-fields and PATCH .../custom-fields/{field_id} do the same for companies.
  • DELETE .../custom-fields/{field_id} removes a value.
Each of these takes field_name and field_value; the value is validated against the field’s type the same way schema values are. Custom fields on custom activity types follow the same five types but are defined as part of the activity type’s schema rather than through this endpoint; see Custom activity types and custom activities. Public API
  • GET/POST /public/custom-fields/schema
  • POST /public/contacts/{contact_id}/custom-fields, PATCH/DELETE .../custom-fields/{field_id}
  • POST /public/companies/{company_id}/custom-fields, PATCH/DELETE .../custom-fields/{field_id}
MCP tools
  • list_custom_fields, create_custom_field
  • update_contact, update_company (accept a custom_fields object of key-value updates)
  • get_filter_schema, get_field_options (custom fields appear as custom.<name>)