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

# Guest details

> The dynamic input fields a variant requires, and how to collect them.

Some variants require additional guest information beyond name/email/phone.

## Input fields

Every booking request requires input fields — these are the data fields collected per customer as part of the booking. They can include standard fields like name, email, and phone, or custom fields like passport number, nationality, meal preference, age, weight, height, and many more.

Headout supports **200+ input field types**, but all of them map to one of **6 data types**:

| Data type | Description |
| :- | :- |
| `Boolean` | True / false selection |
| `String` | Free text input |
| `Integer` | Numeric input |
| `Enum` | Selection from a predefined list of values |
| `Location` | Location input — see handling rules below |
| `Date` | Date input |

**Critical: Location field handling**

The `Location` data type has two distinct behaviors depending on whether the field includes a predefined `values` list:

* **If a** `values `**list is present** → the field only accepts one of the provided value object IDs as input. Render it as a dropdown and pass the selected ID.
* **If no** `values `**list is present** → the field accepts any free-text string as input. Render it as an open text field.

Input fields are **defined dynamically per variant** in the [Product Details API](https://partner.headout.com/docs/api-partner/v2/products/get.md) — these are useful for displaying what a booking requires before the customer picks a slot. However, **input fields can differ between inventories** for the same variant. To render an accurate booking form for a specific inventory, use [Get Inventory Details by ID](https://partner.headout.com/docs/api-partner/v2/inventory/details.md) after the customer selects a slot — this returns the exact fields for that inventory, including the numeric field `id` to submit in the booking request.

Common real-world examples of input fields: **pickup location**, **drop-off address**, **nationality**, **passport number**, **date of birth**, **meal preference**, **hotel name**, **age**, **weight**, and **height**. The set varies per product and per slot.

Form rendering must be fully driven by the API response — never hardcode field assumptions. See [Input Fields](https://docs.google.com/spreadsheets/d/1KYpqKTNvp17WV-huEURDxfcqwF2Iz_Cu357QFAZfVco/edit?gid=1706272551#gid=1706272551) for the full reference.

**Phone number format**

Always submit `PHONE` values in international format: a leading `+`, then the country code and number, with no spaces or punctuation (e.g., `+14155551234`, `+441234567890`).

Each input field specifies the **level** at which data is collected:

| Level | What it means |
| :- | :- |
| `PRIMARY_CUSTOMER` | Field required only for the primary customer |
| `ALL_CUSTOMER` | Field required for every customer in the booking |

#### Guest objects

* A guest object is **required for every pax booked**, regardless of whether input fields are needed for that pax
* The `level` field on each input field determines which guests need that field populated
* For a guest where no input fields are required (e.g. input fields are `PRIMARY_CUSTOMER` only and this is guest 2, 3, etc.) — you must still send a guest object with:
  * `inputFields` array set to **empty** `[]`
  * `paxType` populated
  * `isPrimaryCustomer` set to `false`

⚠️ Every pax must have a corresponding guest object in the booking request. An empty `inputFields` array is valid and expected for non-primary guests when fields are not required for them. Never omit the guest object entirely.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.