Coming soon. Reserved capacity is not yet available. The contract below
may change before launch.
- How much GB can I still reserve here?
- How much do I already hold here?
- What’s the policy cap I’m working under?
Request
curl
| Query param | Required | Notes |
|---|---|---|
from | yes | Window start, aligned to 15 minutes, UTC. |
to | yes | Window end, aligned to 15 minutes, UTC. |
Response
Top-level fields
| Field | Meaning |
|---|---|
generatedAt | When the server computed this snapshot. |
staleAt | After this, refresh before using the snapshot for planning. |
intervalDuration | Always PT15M in v1. |
timezone | Always UTC in v1. |
earliestReservableStart | First interval currently eligible for new reservations. The server enforces a minimum lead time between now and a bookable startsAt. |
Per-interval fields
| Field | Meaning |
|---|---|
startsAt, endsAt | The 15-minute UTC interval. |
reservationLimitGb | Maximum GB this org may commit in this interval (your max_memory_gb). |
reservedGb | Total GB this org already has reserved in this interval. |
reservableGb | Additional GB the server would currently accept. This is the number to plan against. |
reservableGb is the planning field
Everything you need to decide “can I reserve 50 GB at 02:00?” is in
reservableGb. The other fields are context:
reservationLimitGbminusreservedGbis your remaining headroom under your org’s per-interval cap. The server may still reducereservableGbbelow that headroom because of platform-level capacity.reservedGblets you confirm what you already hold without a separate call toGET /api/capacity/reservations.
staleAt is a freshness marker, not a hold
The calendar snapshot is cheap and immediate. staleAt tells you when to
refresh, but capacity can change at any moment — another tenant (or you,
in another tab) may reserve between generatedAt and your write.
This is fine. Writes are atomic and validation is authoritative: if
capacity moved, the write returns capacity_not_available and you read
again.
Race patterns
Plan then write
Plan then write, lost race
- Re-submit with the actual current
reservableGb, or - Accept a smaller amount via multiple writes at different intervals, or
- Bail out — not all demand fits.
Multi-interval request, partial conflict
Choosing the window
The calendar accepts arbitraryfrom–to ranges aligned to the 15-minute
grid. Practical guidance:
- For interactive planning UIs, pull a day or a week at a time; render a
heatmap of
reservableGb. - For scheduled reservation scripts, query just the intervals you’re about to write — don’t pull a week if you only need two hours.
- For large time ranges, expect the response to scale linearly (
4 × hoursrows). Chunk your queries if you need months.
What the calendar does not tell you
- Past reservation events. Use
GET /api/capacity/reservationsfor the audit log. - Other customers’ commitments. Numbers are org-scoped.
- Future limit changes. Your
reservationLimitGbreflects current policy.
Where to go next
Reserving capacity
The write flow, idempotency, atomicity.
Concepts
Vocabulary: intervals, reservations, the log.
Get calendar endpoint
Full request/response reference.