---
title: Glowo REST API
description: The Glowo REST API — base URL, authentication, the OpenAPI specification, and the conventions every endpoint shares.
sidebar:
  icon: terminal
  label: Overview
  order: 0
---

{/* Source of truth: packages/shared/src/routes.ts (Routes registry),
    packages/shared/src/capabilities.ts (the capability vocabulary),
    packages/core/src/http/auth.guard.ts (which credentials the REST guard
    accepts), packages/core/src/http/exception-strategies/
    exception-strategy.interface.ts (the error envelope), and
    packages/api/src/openapi/ (the generator that emits the published spec). */}

Everything the Glowo dashboard does, it does through this API. It is the same
surface your scripts, your CI and your AI agents use.

## The specification

The full machine-readable contract is published as OpenAPI 3.1 at
[glowo.dev/openapi.json](https://glowo.dev/openapi.json).

It is generated from the running controllers rather than written by hand, and a
test fails the build if a route ships without an entry in it. Every operation
carries a unique `operationId`, typed parameters, response schemas, and the
capabilities a credential must hold — which makes it directly usable for
LLM function calling and for client generation.

## Base URL

Every endpoint below is relative to `https://api.glowo.dev`.

## Authenticating

Send a personal access token as a bearer token:

```http
Authorization: Bearer gl_...
```

Keys are created self-serve in the dashboard — see [API keys](/account/api-keys)
for scoping, rotation and revocation. A key belongs to one workspace, carries an
explicit set of capabilities, and declares the surfaces it may be presented on.
A key minted for the `mcp` surface is refused on REST with `403`, and a REST key
is refused on the MCP transport; that separation is the point, not an
inconvenience.

Four capabilities — `workspace:manage`, `billing:manage`, `members:manage` and
`audit:read` — are session-only and can never be attached to a key. The
operations that need them are reachable from a signed-in browser session only.

:::note
Agents are usually better served by the
[Model Context Protocol server](/ai-agents), which exposes a smaller, reviewed
tool surface over OAuth 2.1 instead of a long-lived token in a config file.
:::

## Conventions

**Errors** carry a stable machine-readable `code` alongside a human `message`.
Branch on `code`; the message text is copy and may change.

```json
{
  "statusCode": 404,
  "code": "MONITOR_NOT_FOUND",
  "message": "Monitor not found"
}
```

**Concurrency.** Mutable resources are version-locked. Two writes from the same
read do not silently overwrite one another — the second gets `409` and should
re-read and re-apply.

**Plan limits** return `402` with `PLAN_LIMIT_EXCEEDED` rather than an overage
charge. Existing resources keep working.

**Pagination.** Prefer the cursor-paginated list where one exists — pass the
`nextCursor` from a response back as `cursor`:

```http
GET https://api.glowo.dev/monitors/page
```

**Rate limits** return `429` with a `Retry-After` header.

## A first request

```http
GET https://api.glowo.dev/monitors/stats
Authorization: Bearer gl_...
```

That returns how many monitors are up, down, degraded and paused — the cheapest
answer to "is anything broken right now", and it needs only `monitors:read`.

## Public endpoints

Every published status page also exposes an unauthenticated read API, so you can
surface status in your own tooling without a credential:

```http
GET https://api.glowo.dev/api/v1/status-pages/<slug>/summary
```

See [embeds and badges](/status-pages/embeds-and-badges) for the widget API and
the SVG badge.