Understand registration field definitions

Use stable field IDs to interpret attendee answers without relying on duplicate or renamed labels.

Registration fields are the questions an organizer configures for attendees, such as name, email, city, company, designation, or event-specific questions.

Request the field definitions

GET /v1/events/{eventId}/custom-fields
Required scope: events:read

Example:

curl --request GET \
  'https://api.meraevents.com/v1/events/501/custom-fields' \
  --header 'x-api-key: YOUR_SECRET_TOKEN'

The response contains groups and fields:

{
  "groups": [
    {
      "id": 20,
      "title": "Professional details",
      "description": "Tell us about your work",
      "order": 2,
      "collapsedByDefault": false
    }
  ],
  "fields": [
    {
      "id": 105,
      "groupId": 20,
      "fieldName": "Company Name",
      "fieldDescription": "Your current organization",
      "fieldType": "textbox",
      "fieldLevel": "event",
      "fieldMandatory": false,
      "displayOnTicket": false,
      "minLength": null,
      "maxLength": 120,
      "options": [],
      "appliesToTicketIds": [101, 103],
      "displayOrder": 4
    }
  ]
}

Use the ID, not the field name

fields[].id is the authoritative identifier. Store and match answers by this value.

Do not use fieldName as a database key because:

Two fields can have the same label.
An organizer can rename a field.
Capitalization and spacing can change.
Different events can use the same label for different questions.

The registrations endpoint includes both fieldId and fieldName. The name is a display convenience; the ID is the join key.

registration.attendees[].customFields[].fieldId
                         │
                         └── matches custom-fields.fields[].id

Interpret each definition

Field	Meaning
`groupId`	Nullable ID of the group containing the field
`fieldType`	Control/value type configured for the registration form
`fieldLevel`	Whether the question applies at event or ticket level
`fieldMandatory`	Whether the attendee must answer it when applicable
`options`	Allowed choices for selection fields; empty for free-text fields
`appliesToTicketIds`	Ticket IDs for which the field is applicable
`displayOrder`	Organizer-defined ordering within the form

Use the fields returned by the API rather than maintaining your own hard-coded list of field names.

Recommended integration pattern

Fetch /custom-fields for the event.
Build a lookup keyed by String(field.id).
Fetch /registrations.
Match every attendee answer using fieldId.
Use the current definition's fieldName when displaying or exporting the answer.
Preserve unknown IDs instead of dropping their values; refresh the definitions and try the lookup again.

You can cache field definitions because they change less frequently than registration data. Refresh them when the organizer changes the form, when an unknown fieldId appears, or before a complete export.

Groups and ticket applicability

Groups organize the form for display. They do not replace field IDs. A field with a groupId should be placed under the matching groups[].id when reconstructing the form.

Use appliesToTicketIds when the same event has different questions for different tickets. Do not assume every field applies to every attendee.

Next step

Read registration and attendee data, then join every submitted answer to these definitions using fieldId.