Custom fields and item types

Every HQ account can add its own fields to reservations, contacts, vehicles and other records.
Their IDs differ from account to account, so look them up instead of hard-coding them.

Find the fields of a record type

GET /fields?item_type=<item type> lists the fields of one item type, 10 per page by default.

Each field has an id, a label, a type, a required flag and a dbcolumn.
The ID is also in the # column of Settings > Items > Fields in HQ.

Item types

`item_type`	Records
`car_rental.reservations`	Reservations
`car_rental.reservation_vehicle_information`	Pick-up and return information of a reservation
`car_rental.reservation_payments`	Reservation payments
`car_rental.reservation_refunds`	Reservation refunds
`car_rental.drivers`	Drivers of a reservation
`contacts`	Fields shared by all contacts
`contacts.<category_id>`	Fields of one contact category, for example `contacts.3`
`fleets.vehicles`	Vehicles
`fleets.vehicle_classes`	Vehicle classes
`fleets.locations`	Locations
`fleets.additional_charges`	Additional charges
`invoices`	Invoices
`quotes`	Invoice quotes
`sheets.<sheet_id>`	Items of a form (forms are called sheets in the API)

Send and read values

Send a custom field as field_<id>:

Responses return the value under the field's dbcolumn, for example f254; built-in fields keep their own name, such as first_name.
To filter a list by a custom field, use field_<id> as the filter column (see Filtering and incremental sync).

Reservation payments and refunds keep their data in fields, so their write endpoints expect field_<id> keys for every value.
The booking customer step (POST /car-rental/reservations/customer) and POST /car-rental/reservations/confirm also accept first_name, last_name and birthdate directly; send every other contact field as field_<id>.

How the API writes fields

When you create or update contacts through the contacts endpoints, reservations (update) or form items, create invoices, or update vehicles, through the API:

Partial updates: fields you do not send keep their value.
On POST /car-rental/reservations/{reservation_id}/update, always resend additional_drivers: when the request has neither additional_drivers nor reservation_rates, every additional driver that is not sent is removed, so an update that only changes the dates removes them.

Clearing a field: an empty value is ignored unless you also send include_empty_fields=1.

No Settings validation: the rules configured in Settings > Items > Fields, such as required fields and show or hide conditions, are not enforced, so validate the data in your integration.

Permissions: a field the API user is not allowed to edit is ignored without an error.
Some field types, such as Tags, Phone, Address and Email, are still written, so use an administrator user and do not rely on permissions to protect fields.

Reservation payments and refunds do validate their fields with the rules from Settings, and an update replaces every field: a field you do not send goes back to its default or empty value.
The booking customer step and confirm work the same way for the contact: with contact_id or external_contact_id, every contact field you do not send is cleared on the existing contact.

Find the fields of a record type#

Item types#

Send and read values#

How the API writes fields#

Find the fields of a record type

Item types

Send and read values

How the API writes fields