---
title: "Get Zone Day Use Window"
method: GET
path: "/api/v1/parks/zones/{zone_id}/day-use-window"
tags: ["parks"]
---

# Get Zone Day Use Window

`GET /api/v1/parks/zones/{zone_id}/day-use-window`

## Request

- Base URL: `https://api.alert.camp` (the document declares no server; this is the origin it was published from)
- URL: `https://api.alert.camp/api/v1/parks/zones/{zone_id}/day-use-window`
- Auth: none declared

The dates a day-use zone's time-slot grid should offer.

Day use is seasonal and the season is published NOWHERE in the provider
API — it is only visible in the availability grid, and it moves as the
provider releases next season.  So the grid asks for it per zone rather
than assuming a fixed number of columns.

``max_span_days`` rides along so the client can cap a SELECTION without
capping the VIEW: the user browses the whole season but can only watch a
window the platform's alert date-range cap allows.

``closed_cells`` ({site_id: ["YYYY-MM-DD", ...]}) names the cells the grid
must not let the user tap because their booking window has ALREADY shut.
Day use is the one activity whose inventory dies during its own arrival
day — each slot carries its own cutoff — so "not in the past" is not
enough to know a cell is live.  Computed here rather than shipped as raw
cutoffs because deciding it needs the park's IANA timezone, and the app
carries no tz database (Bruce is America/Toronto, Banff America/Edmonton).
Read-time, never stored, exactly like a match's ``booking_closed``.

Degrades to a bare cap (``start``/``end`` null) whenever the window can't
be read — an unreachable provider must not empty the grid.

## Path parameters

- `zone_id` string, required

## Response `200`

Successful Response

- object

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/alert/apis/alertcamp.md) · [All operations](https://skmtc.dev/alert/apis/alertcamp/llms.txt) · [OpenAPI document](https://skmtc.dev/alert/apis/alertcamp/revisions/864c8c9ef833?raw)