---
id: rooms
slug: /apis/rooms
title: 'Rooms & Panels'
description: 'api/teamroom and api/planningroom — configure the panels shown in a Team Room or Planning Room.'
sidebar_label: 'Overview'
sidebar_position: 1
tags: ['api', 'rooms', 'panels', 'team-room', 'planning-room']
---

Two endpoints supporting Agility's room features. These are **configuration APIs for the
Agility UI** rather than general-purpose data APIs — they manage which panels appear in a room
and which saved views exist, not the work items inside them.

Rooms themselves are ordinary assets: create and configure a `TeamRoom` or `PlanningRoom`
through the [data APIs](/apis/rest-1), then use the panel APIs here to arrange what the room
shows. That split is deliberate — these endpoints exist so room provisioning can be automated
at scale.

| Endpoint | Purpose |
| --- | --- |
| [`api/teamroom`](/apis/rooms/panels) | Panels in a Team Room |
| [`api/planningroom`](/apis/rooms/panels) | Panels in a Planning Room |

:::note Saved views and room configuration are not published yet
The `rooms2`-family endpoints (`api/rooms2views`, `api/rooms2config`) exist but
are deliberately undocumented here for now: they are still settling as the new
rooms experience builds on them, and we would rather publish a stable contract
than revise one. They will appear here when their use stabilizes.
:::

## Authorization Is Stricter Than Read Access

The two panel APIs require the **`EditRoom`** right on every route, including the ones that only
read. Listing the available panels needs the same permission as installing one.

They also require a **room context**, supplied as a `roomContext` parameter, which the server
establishes before the action runs.

## The Two Panel APIs Are Similar but Not Interchangeable

`api/teamroom` and `api/planningroom` look like the same API twice and are close enough that
assuming symmetry is tempting. They differ in three ways, each of which will break a client that
assumes otherwise — see [Room panels](/apis/rooms/panels) for the comparison.