Custom Fields

Custom fields are the extra label/value rows users add to a schedule item, venue, or stay — door codes, wifi passwords, promoter notes, and so on. The three resources have near-identical shapes, differing only in the ID they take and whether they support premade templates.

Resource	Path prefix	Templates?
Schedule item	`/v1/schedule/items/{itemId}/custom-fields`	No
Venue	`/v1/venues/{venueId}/custom-fields`	Yes
Stay	`/v1/accommodation/{accommodationId}/custom-fields`	Yes

Two ways to write them

If you are already creating or updating the parent record, just include a customFields array in that request — it is simpler and costs one call. Use the dedicated endpoints below when you want to change fields without rewriting the record.

Inline (on POST/PUT of the item, venue, or stay) is a full replace — the array you send becomes the complete set, and no operation is used:

{ "customFields": [{ "title": "Door code", "description": "4417" }] }

Dedicated (below) reconciles per field, so you can add one without resending the others.

Read custom fields

GET /v1/schedule/items/{itemId}/custom-fields
GET /v1/venues/{venueId}/custom-fields
GET /v1/accommodation/{accommodationId}/custom-fields

Scope: schedule.read / venues.read / accommodation.read Response data — array of fields:

[
  { "id": 1557, "template_key": null, "title": "Door code", "description": "4417", "sort_order": 0 },
  { "id": 1558, "template_key": "venue_type", "title": "Venue type", "description": "Amphitheater", "sort_order": 1 }
]

Schedule item fields have no template_key. Custom fields are also embedded in the records themselves — customFields on GET /v1/accommodation/{id} and on schedule items, venueCustomFields on GET /v1/venues/{id}.

Add, update, or remove fields

PUT /v1/schedule/items/{itemId}/custom-fields
PUT /v1/venues/{venueId}/custom-fields
PUT /v1/accommodation/{accommodationId}/custom-fields

Scope: schedule.write / venues.write / accommodation.write Body

Field	Type	Required	Description
`fields`	array	Yes	The operations to apply.

Each entry:

Field	Type	Required	Description
`operation`	string	Yes	`ADD`, `UPDATE`, or `REMOVE`.
`id`	number	For `UPDATE`/`REMOVE`	The existing field.
`title`	string	For `ADD`	Field label.
`description`	string	No	Field value.
`sortOrder`	number	No	Display order.
`templateKey`	string	No	Venues and stays only — use a premade field.

Only the fields you list are touched. Omitting an existing field leaves it alone — this is not a full replace, unlike the inline form.

Example — add one field and delete another in a single call:

curl -X PUT "$BASE/v1/venues/3719/custom-fields" \
  -H "x-api-key: $KEY" -H "x-api-secret: $SECRET" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "fields": [
      { "operation": "ADD", "title": "Wifi password", "description": "loadin2026" },
      { "operation": "REMOVE", "id": 1557 }
    ]
  }'

Response data: none.

Premade fields (templates)

Venues and stays have a catalogue of premade fields. Pass templateKey instead of title and the server supplies the label:

{ "operation": "ADD", "templateKey": "confirmation_number", "description": "JDSHA6565AH" }

Read the available keys from GET /v1/reference/venue-field-templates and GET /v1/reference/stay-field-templates. Omit templateKey for a free-form field — then title is required.

On stays, the premade confirmation_number field is column-backed: writing it updates the stay’s booking_number and creates no custom-field row. It will not appear in the custom-fields list, and its id comes back null.

See also: Schedule, Venues, Accommodation, Reference Data.

Get started

Endpoints

Guides

Reference

Two ways to write them

Read custom fields

Add, update, or remove fields

Premade fields (templates)

​Two ways to write them

​Read custom fields

​Add, update, or remove fields

​Premade fields (templates)

Two ways to write them

Read custom fields

Add, update, or remove fields

Premade fields (templates)