Skip to main content
POST
Preview a request (dry run)

Authorizations

X-API-KEY
string
header
required

Body

application/json
start
string
required

Start/end of the request in ISO 8601. For day-based leave types (leave_unit: days) send the date at midnight UTC (e.g. 2026-06-01T00:00:00Z) and use start_at / end_at to set half-days. For hour-based leave types include the exact time of day (e.g. 2026-06-01T09:00:00Z); start_at / end_at are then ignored.

end
string
required

Start/end of the request in ISO 8601. For day-based leave types (leave_unit: days) send the date at midnight UTC (e.g. 2026-06-01T00:00:00Z) and use start_at / end_at to set half-days. For hour-based leave types include the exact time of day (e.g. 2026-06-01T09:00:00Z); start_at / end_at are then ignored.

leave_type_id
string<uuid>
required
Pattern: ^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$
requester_member_id
string<uuid>
required
Pattern: ^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$
start_at
enum<string>

For day-based leave types: whether the absence starts in the morning (the whole first day counts) or afternoon (only the second half of the first day). Ignored for hour-based leave types.

Available options:
morning,
afternoon
end_at
enum<string>

For day-based leave types: whether the absence ends at lunchtime (only the first half of the last day) or end_of_day (the whole last day counts). Ignored for hour-based leave types.

Available options:
lunchtime,
end_of_day
reason
string
representative_member_ids
string<uuid>[]

Member IDs to assign as representatives. Required for leave types that mandate representatives; omitting them returns REQUIRED_REPRESENTATIVES_COUNT_NOT_MET (as a 400 on create, as rejection.code on preview).

Pattern: ^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$
ignoreRepresentativeRequirement
boolean

Skip the representative requirement. Only honored when the API key's member is an admin and the request is created for another member.

Response

Successful response

can_create
boolean
required

The one-line verdict: true means POST with this payload passes every rule the create endpoint applies, as of the data at preview time; false means it fails. False whenever rejection is set, a blocking conflict is listed or is_allowance_sufficient is false. Two things the preview cannot see: requests created in between, and changes to the member's approvers that the create call makes when approver sync from Microsoft 365 is on. A snapshot, not a reservation.

duration
object | null
required
takes_from_allowance
boolean
required
allowance_type
object | null
required

The allowance the absence deducts from. Null when it deducts nothing.

is_allowance_sufficient
boolean | null
required

True means the allowance covers this payload, false means creating it fails with the allowance error. Always true for leave types that do not deduct. Null when rejection is set: the allowance was not evaluated. conflicts is reported separately and does not affect this flag.

conflicts
object[] | null
required

Existing non-declined, non-cancelled requests of the member that overlap the absence, regardless of their leave type. Any entry blocks creation. Null when the payload was rejected before the overlap check ran (START_AFTER_END through OUTSIDE_EMPLOYMENT_PERIOD); populated for every later rejection so both problems are visible at once.

rejection
object | null
required

Set when creating the same payload would be rejected with 400: the first failing rule, in the order the create endpoint applies them. Overlapping requests and the allowance are never a rejection; see conflicts and is_allowance_sufficient. duration and is_allowance_sufficient are null when this is set. Match on code, not on message (which is translated into the API key member's language).