# The areas of the reference

The served specification organizes its 443 operations into 19 areas (tags) and 7 groups, and the reference shows them in exactly this order. Read the tables as a map: what an area contains, whether an API key may do anything there, and which command group of the command line corresponds to it.

> **Type:** reference
> **For:** Anyone who looks for an area in the reference or wants to know where a resource lives.
> **Prerequisite:** none

The column **With key** is derived from the permission catalog: “yes” means the permissions of the area are key-capable. “partial” means some routes need only authentication or a key-capable permission, and the rest need a session. “session” means no permission of the area is intended for keys. “no sign-in” means the route needs no credential. What a key can carry is described under [Authentication](/api/authentication).

## Identity & access

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `identity` | User accounts, the user’s own profile, and the means of access of an organization: create, suspend, and reactivate accounts, second factor with recovery codes, API keys, linked provider accounts, plus [delegated access](/api/oauth-delegated-access) with its endpoints outside `/v1` and the [SCIM surface](/api/scim-provisioning) under `/scim/v2`. | partial (`GET /v1/me`) | `user`, `api-key`, `invitation`, `operator` |
| `sessions` | All ways into a session: password, sign-in link, platform-wide providers, company sign-in, second factor, organization choice. Plus refreshing and ending, resetting a password, and impersonation by the operator. | session (public sign-in routes) | `whoami` |
| `access` | Roles and individual grants, the catalog of all assignable permissions, and the effective permissions of the signed-in account. | partial (`GET /v1/permission-catalog`, `GET /v1/me/permissions`) | `role`, `grant`, `permission` |
| `onboarding` | Self-registration with email confirmation, invitations including the public acceptance page, join requests, and the setup assistant. | session | `invitation`, `self-registration` |

## Organization & billing

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `tenancy` | The organization itself: master data, business profile, brand, custom domain, and company sign-in with its verified domains. Operators keep the list of organizations and suspend or release them. | partial (`GET /v1/me/capabilities`) | — (you maintain master data in the portal) |
| `billing` | Book, change, cancel, and reactivate a package. View payment methods and invoices, check usage limits. Operators maintain the article catalog and process invoices and refunds. | partial (`GET /v1/me/licensing`) | `subscription`, `invoice`, `catalog` |

## Content & planning

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `cloud-connections` | The authorizations for third-party storage accounts from which the media library feeds its places: round trip to consent, state of all connections, disconnecting. Access and refresh tokens never leave the server. | session | — |
| `media-library` | The media inventory: upload including multipart uploads, folders and dynamic collections, renaming and moving in bulk. For each media item: download links, variants, usage records, trash, and permanent deletion. | yes | `asset`, `folder` |
| `composition` | Create scenes, generate them from templates, publish, archive, and restore. Every change is versioned, versions can be compared and rolled back, and integrity findings can be checked and cleared. | yes | `scene`, `scene-version`, `scene-template`, `layout`, `widget` |
| `scheduling` | What runs when: assemble playlists, create, pause, and resume programs, determine the default scene. Plus calendar view and conflict preview. | yes | `playlist`, `schedule`, `display-group`, `player` (program and override) |
| `advertising` | The organization’s advertising, in the stability class `beta`: advertisers, ad campaigns with their bookings, the reach of a booking (`GET /v1/advertising/booking-lines/{id}/reach`), and the preview of what a booking would deliver (`POST /v1/advertising/booking-lines/preview`). Also creatives from the organization’s own media library with their approval, the ad space per display, the audience per location, participation in the ad network with its parameters, and the monthly revenue statements from the ad network with the distribution per ad campaign and the credit note (`GET /v1/advertising/revenue`). Creating and changing require the `advertisingDirect` capability of the package. | yes | `advertiser`, `campaign`, `booking`, `creative` |

## Apps & marketplace

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `app-catalog` | The origin side of apps: Operators fetch releases from the registry, check them, release them (to stable with a second person), demote them, withdraw them, control phase-out periods, and set exceptions per organization. Publicly served are the manifest, bundle, and authoring module of an app version as well as the catalogs of the widgets (`GET /v1/widget-catalog`, with the graphics library of the graphic widget under `GET /v1/widget-catalog/graphics`) and of the resource types (`GET /v1/resource-type-catalog`) across all apps, plus the versions of an app with their date and what is new in them (`GET /v1/apps/{appId}/history`). | partial (public delivery, both catalogs) | `app-release`, `app-status` |
| `marketplace` | The organization’s view of the app offering: discover, install, update, and uninstall with a preview of the consequences. Deciding on an update: the open decisions (`GET /v1/me/apps/updates`), those of one app (`GET /v1/me/apps/{appId}/update`), accept and reject (`POST …/update/accept`, `POST …/update/reject`). Opting in to versions from the beta channel, for all apps (`GET\|PUT /v1/me/apps/beta-enrollment`) or per app (`POST\|DELETE /v1/me/apps/{appId}/beta-enrollment`). Plus the organization’s own inventory, the installed apps (`GET /v1/me/apps`). The store returns its state fully resolved: the overview as cards (`GET /v1/me/apps/store`), the listing of an app (`GET /v1/me/apps/store/{appId}`), the collections (`GET /v1/me/apps/collections`), and the page of an installed app with its scenes and the history of its consents (`GET /v1/me/apps/{appId}/installed`). Anyone who may not decide alone asks the Owners for an installation (`POST /v1/me/apps/{appId}/install-request`) or for the decision on an update (`POST /v1/me/apps/{appId}/update/decision-request`). You read the data of an uninstalled app with `GET /v1/me/apps/{appId}/data`, schedule its deletion after 30 days with `POST /v1/me/apps/{appId}/data/deletion`, and cancel it with `DELETE /v1/me/apps/{appId}/data/deletion`. | partial (`GET /v1/me/apps/store`) | `app` |

## Fleet & playback

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `fleet` | The playback devices: commissioning via pairing code, tags, remote commands with feedback, removing displays. Devices report check-ins, capabilities, and the history of their updates. The actions on the device itself (re-pair, factory reset, remove, block) are under `identity`. The [locations](/api/locations) also live here, as the folder above the displays, the [web displays](/api/web-displays) that run in the browser without a device, and the screenshots of a display as a time series (`GET /v1/players/{playerId}/screenshots`). | partial (`location.*`, `fleet.player.list`, `…read`, `…update`, `…command.issue`, `fleet.web-display.manage`) | `device`, `player`, `location`, `playback` |
| `playback` | The interface to the renderer: load the playback package, report the start, deliver diagnostic logs. Plus preview of widget data and delivery of the renderer bundle. | session (device or operator) | `playback` |

## Monitoring & notifications

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `audit` | The tamper-evident audit log: search entries, group operations by their correlation, export extracts. Operators pseudonymize entries with personal data and resolve pseudonyms. | session | `audit` |
| `notifications` | Inbox in the portal, personal delivery channels, and webhooks including delivery log, redelivery, and rotation of the secret, plus the [event catalog](/webhooks/fetch-event-catalog) from which a list of subscribed event types is built. | session | `webhook` |
| `analytics` | Analyze ad hoc against the metric catalog and output the result as CSV or PDF, along with the overview, the day and the log of a display, the organization’s own content, and the delivery of an ad campaign. Save views, deliver them on a schedule and download them, query metrics, plus the cleanup overview that counts what is left lying around. The location is an axis of the ad hoc analysis. Also the proofs of the bookings with their interim statement, the links for advertisers, and (without sign-in) the verification of a proof and the campaign report behind a link. | partial (`analytics.query.run`, `analytics.proof.read`, `analytics.proof.manage`) | `analytics`, `hygiene`, `proof` |

## Platform operations

An area with two routes without sign-in. The rest of the operator surface is **not** in this specification (see below).

| Tag | What you find there | With key | Command line |
|---|---|---|---|
| `status` | The two operational routes that anyone may call: the status of the platform as the status page shows it (`GET /v1/public/status`) and the current maintenance window (`GET /v1/public/maintenance-status`). | no sign-in | `health public` |

### What is not here: the operator surface

The API also carries around 280 operations under `/v1/platform/…`: queues, caches, signing keys, permission catalog, event dispatcher, audit log operations. They are the **inside view of the house**: They are for the platform operator, not for your organization, and a key or a session of an organization gets `403 Permission.OperatorOnly` there.

These routes are therefore **not part of this reference**, and the specification at `/api/openapi.json` does not contain them: A generated client gets only what you may also call. Anyone who operates the platform themselves finds the operator version on their own environment behind a sign-in.

## What else the reference does not show

| Surface | Why not |
|---|---|
| The operational routes `GET /health/live`, `GET /health/ready`, `GET /health/version`, and `GET /metrics` | They are marked `internal`: They describe the state of an environment, not your inventory. They still answer without sign-in, and `szenera health` queries them. |
| The operation of installed apps and the information about open realtime connections | also `internal`, the inside view of the runtime. |
| Routes that an app brings along (`/v1/apps/<app-id>/…`) | Which ones exist depends on the app inventory of your environment. A release state cannot know them. |

What `internal` means and what the public version promises instead is described under [Stability classes and sunset](/changes/stability-and-sunset).

## Related

- [Read the reference](/api/read-reference)
- [Stability classes and sunset](/changes/stability-and-sunset)
- [Commands for your organization](/cli/commands-organization)