Skip to main content
Workspaces definem os seus próprios campos em registros do CRM. Eles chegam num objeto aninhado com keys estáveis:
Dessa forma seguem duas coisas. As keys são legíveis e estáveis. custom_fields.segment é a key do campo, não um id opaco, então o seu código lê do jeito que o workspace fala. A key é fixada na criação; renomear o label de um campo na Sailer não a move. Os valores são tipados. Um campo numérico devolve um JSON number, um checkbox devolve um boolean, uma data devolve uma string de data ISO-8601. Eles não vêm stringifyados.

​
Descobrir os campos que um workspace usa

GET /v1/fields lista cada campo definido num resource, built-in e personalizado: key, label, type, se é required ou read-only, e os valores permitidos dos selects. Passe entity=contact, entity=organization ou entity=deal para restringir a lista; omita para listar o workspace inteiro.
Use a key que ele devolve dentro de custom_fields no create e no update. Adivinhar a partir de outro workspace — ou desta documentação — é como você leva um erro de unknown-field. No MCP, a mesma tabela é describe_schema. Chame primeiro; clientes cacheiam schemas de tools por servidor, não por tenant, então campos personalizados nunca vão na própria tool. Todo campo personalizado definido na entidade também aparece em todo registro, com null onde um registro não tem valor. Ler um registro mostra as keys em uso, mas não os tipos nem os valores permitidos — para isso existe /v1/fields.

​
Como escrevê-los

Envie só as keys que você quer mudar. Campos não listados ficam como estão:
Para limpar um campo, envie null. Enviar uma key desconhecida, ou um valor do tipo errado, devolve 422 com a key ofensora em error.detail.