> ## Documentation Index
> Fetch the complete documentation index at: https://docs.daysync.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom Fields

> Read and manage the free-form and premade extra fields on schedule items, venues, and stays.

**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

<Tip>
  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.
</Tip>

**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:

```json theme={null}
{ "customFields": [{ "title": "Door code", "description": "4417" }] }
```

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

***

## Read custom fields

```text theme={null}
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:

```json theme={null}
[
  { "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}`](/endpoints/accommodation) and on schedule items, `venueCustomFields` on [`GET /v1/venues/{id}`](/endpoints/venues).

***

## Add, update, or remove fields

```text theme={null}
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. |

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

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

```bash theme={null}
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:

```json theme={null}
{ "operation": "ADD", "templateKey": "confirmation_number", "description": "JDSHA6565AH" }
```

Read the available keys from [`GET /v1/reference/venue-field-templates`](/endpoints/reference) and [`GET /v1/reference/stay-field-templates`](/endpoints/reference).

Omit `templateKey` for a free-form field — then `title` is required.

<Warning>
  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`.
</Warning>

***

See also: [Schedule](/endpoints/schedule), [Venues](/endpoints/venues), [Accommodation](/endpoints/accommodation), [Reference Data](/endpoints/reference).