Skip to content
Core API
Esc
navigateopen⌘Jpreview

Custom field definitions

Custom field definitions: available fields, filters, associations, and API operations.

Path: events/{event_id}/custom-field-definitions
Methods: GET collection/record, POST, PATCH. There is no DELETE operation.

GET

  • Fields: event-id, key, title, customizable-type, visible-to-sponsors, filterable, role, field-type, options, position, visible-on-registrant-profile, required, created-at, updated-at, is-onboarding-question.
  • Filters: customizable_type, role, visible_to_sponsors, filterable.
  • Association: onboarding_step_questions → response onboarding-questions, with onboarding-step-id, title, description, position, required.
GET .../custom-field-definitions?customizable_type=Event%3A%3ARegistrant&include=onboarding_step_questions

POST/PATCH inputs: key, title, customizable_type, visible_to_sponsors, filterable, field_type, options (array), and visible_on_registrant_profile.

{
  "key": "linkedin_url",
  "title": "LinkedIn URL",
  "customizable_type": "Event::Registrant",
  "field_type": "Text",
  "options": [],
  "visible_to_sponsors": true
}

Event::Invite is normalized to Event::Registrant on create. Unsupported customizable types and duplicate keys are rejected. key and customizable_type cannot be changed through PATCH; attempts are ignored. The request parameter visible_on_registrant_profile maps to the underlying writable field exposed in introspection as visible_on_attendee_profile.

Despite its name, is-onboarding-question is the count of onboarding-step question rows for the definition, normally 0 or 1, rather than a JSON boolean.

Last updated on August 21, 2026