Checking availability through the API

With the GET /api/v1/availability endpoint your own system asks Univents whether a period is free: for a single room or for every room of a workspace. That lets your website, your planning tool or another system give an answer without creating a booking.

The statement is the same one the booking page and the assistant use: booked events, run-of-show items, room groups, open enquiries and blocked periods all count.

Key and permission

You need an API key with the Read locations permission. You create it under Integrations → Developer → API keys — the setup is described in the API keys article. Send it with every request as Authorization: Bearer <key>. A key without that permission gets a refusal, not an empty result.

The request

GET /api/v1/availability?from=2026-10-01&to=2026-10-03
GET /api/v1/availability?from=2026-10-01T18:00&to=2026-10-01T23:00&location_id=<room id>
GET /api/v1/availability?from=2026-10-01&to=2026-10-03&buffer_minutes=120&include_soft_holds=false

Without a time zone, date and time are read in your workspace's time zone. If you append a Z or an offset (2026-10-01T18:00Z), the value is taken literally.

The answer

{
  "available": false,
  "window": {
    "requested_from": "2026-10-01",
    "requested_to": "2026-10-03",
    "from": "2026-09-30T22:00:00.000Z",
    "to": "2026-10-03T22:00:00.000Z",
    "buffer_minutes": 120
  },
  "free_location_ids": ["…"],
  "locationAvailable": false,
  "conflicts": [
    {
      "type": "event_overlap",
      "location_id": "…",
      "from": "2026-10-02T15:00:00.000Z",
      "to": "2026-10-02T22:00:00.000Z",
      "confirmed": true
    },
    {
      "type": "soft_hold",
      "location_id": "…",
      "from": null,
      "to": null
    }
  ],
  "notes": ["Soft holds (open, non-archived requests) are counted per day …"]
}

• available — free or not, across every room that was checked. When you asked for a single room, locationAvailable is added for that room.
• window — what was actually checked. With a buffer the window is wider on both sides than what you asked for; requested_from/requested_to still show what you sent.
• free_location_ids — the rooms that are free in the window.
• conflicts — what is in the way. type says what it is:

• degraded — present only when part of the check could not be read. The answer is then not conclusive: do not treat it as a commitment, ask again.
• notes — the fine print you need in order to read the answer correctly; see below.

What the answer is not

• Not a booking. The call reserves nothing. Between the request and your booking another process can take the room — the booking itself checks again.
• No personal data. The answer names room identifiers and periods, no names, no contacts, no contact persons.
• No page-level limit. The limit for parallel enquiries is configured per booking page, and an API call has no page context. That is why it is not part of this answer — its absence is not a zero.
• The day that is not the minute. Blocked periods and open enquiries are evaluated per calendar day in the workspace's time zone, while events are compared to the minute. That makes the result never more permissive than the booking page, but it can be stricter. The notes in the answer say so for the case at hand.

Error cases

An empty window or a typo in the date never turns into "free" — such requests are rejected. You find the full description of the endpoint, including all of its parameters, in the API reference at /api/v1/docs.