Skip to main content
Los workspaces definen sus propios campos en los registros del CRM. Llegan en un objeto anidado con keys estables:
De esa forma se siguen dos cosas. Las keys son legibles y estables. custom_fields.segment es la key del campo, no un id opaco, así tu código lee como habla el workspace. La key se fija al crearlo; renombrar el label de un campo en Sailer no la mueve. Los valores están tipados. Un campo numérico devuelve un JSON number, un checkbox un boolean, una fecha un string de fecha ISO-8601. No van stringifyados.

​
Descubrir los campos que usa un workspace

GET /v1/fields lista cada campo definido en un resource, built-in y personalizado: key, label, type, si es required o read-only, y los valores permitidos de los selects. Pasa entity=contact, entity=organization o entity=deal para restringir la lista; omítelo para listar todo el workspace.
Usa la key que devuelve dentro de custom_fields en create y update. Adivinar desde otro workspace — o desde esta documentación — es cómo obtienes un error de unknown-field. En MCP, la misma tabla es describe_schema. Llámalo primero; los clientes cachean schemas de tools por servidor, no por tenant, así que los campos personalizados nunca van en la tool misma. Cada campo personalizado definido en la entidad también aparece en cada registro, con null donde un registro no tiene valor. Leer un registro muestra las keys en uso, pero no sus tipos ni valores permitidos — para eso está /v1/fields.

​
Cómo escribirlos

Envía solo las keys que quieres cambiar. Los campos no listados se dejan igual:
Para vaciar un campo, envía null. Enviar una key desconocida, o un valor del tipo incorrecto, devuelve 422 con la key ofensora en error.detail.