Create a custom field value
Creates a single custom field value attached to one of a user, a contact, or an event attendance (exactly one of user, contact, eventAttend must be set; the others must be omitted or null). The field IRI is required. For file-type custom fields, send a media IRI and the value will be ignored; for other field types, send value as a string (callers should JSON-encode multi-option answers themselves before sending).
All foreign-key fields take an IRI-reference string in the form /api/v1/{resource}/{id} rather than plain numeric ids. Concrete examples are listed in the “Request body” section below.
Permission gates per owner type mirror the existing PATCH endpoints on the owning entities:
user: caller is the user, hasHR_LOCALon the user, or is a parent of the user.contact: caller hasHR_LOCALorFINANCIAL_LOCALon the contact.eventAttend: caller is the attendee, hasEVENT_LOCALon the event’s unit, or hasHR_TENANT.
For contact-attached values the field’s tenant must match the contact’s tenant and the field’s discriminator must be profile; for event-attended values the field’s tenant must match the event’s tenant and the discriminator must be event. The user-attached path inherits the existing nested-write behavior, which does not enforce either of those checks today.
Authorizations
Server-to-server authentication. Generate a token in the admin UI at
Settings → Developers → API Access. Send the raw token in the
Api-Token header — there is no Bearer prefix.
Tokens can be marked read-only at creation time, in which case the API
rejects any non-GET request with 403 Forbidden.
Body
The new CustomFieldValue resource
Stored answers for tenant-defined custom fields. Each row links a CustomField definition to one of three possible owners: a user (user), a contact (contact), or an event attendance (eventAttend). Exactly one of these is set per row; the others are null. The value column holds the answer as a string (multi-option fields store a comma-separated list, file/image fields store the answer in media and leave value blank). All queries are tenant-isolated through field.tenant, which is guaranteed non-null. The endpoint exposes only the values whose custom field definition belongs to the current user's tenant. Custom field values attached to event attendances are typically read through /event_attends/{id} rather than this collection. Values can be created directly through POST on this resource (one value per request, with exactly one of user/contact/ eventAttend set), or as nested writes inside the owning entity (e.g. PATCH /users/{id} with a rawUserCustomFieldsValues map, PATCH /contacts/{id} with rawContactCustomFieldsValues). The direct POST route delegates to the same underlying service as the nested-write path, so encryption, file-media handling, and field-visibility checks behave identically.
"/api/v1/custom_fields/1"
"/api/v1/users/1"
"/api/v1/contacts/1"
"/api/v1/media/1"
"/api/v1/event_attends/1"
Response
CustomFieldValue resource created
Stored answers for tenant-defined custom fields. Each row links a CustomField definition to one of three possible owners: a user (user), a contact (contact), or an event attendance (eventAttend). Exactly one of these is set per row; the others are null. The value column holds the answer as a string (multi-option fields store a comma-separated list, file/image fields store the answer in media and leave value blank). All queries are tenant-isolated through field.tenant, which is guaranteed non-null. The endpoint exposes only the values whose custom field definition belongs to the current user's tenant. Custom field values attached to event attendances are typically read through /event_attends/{id} rather than this collection. Values can be created directly through POST on this resource (one value per request, with exactly one of user/contact/ eventAttend set), or as nested writes inside the owning entity (e.g. PATCH /users/{id} with a rawUserCustomFieldsValues map, PATCH /contacts/{id} with rawContactCustomFieldsValues). The direct POST route delegates to the same underlying service as the nested-write path, so encryption, file-media handling, and field-visibility checks behave identically.
"/api/v1/custom_fields/1"
"/api/v1/users/1"
"/api/v1/contacts/1"
"/api/v1/event_attends/1"

