api reference

These docs explain the why and how. The OpenAPI reference is authoritative on the what — each endpoint's request shape, response shape, status codes, and validation rules.

The reference covers the public API: the stable, versioned subset meant for automation (the CLI, the MCP server, and your own scripts). It's backward-compatible within /v1 — additive changes only; breaking changes ship under a new major version. Internal endpoints the web app uses are intentionally not documented and carry no stability guarantee.

authentication

Two credential paths reach the same API and resolve to the same user:

• Session cookies — what the web UI uses. Set as HttpOnly cookies by the backend after login; you never handle them directly.
• Bearer token — Authorization: Bearer pngr_pat_…, using a personal access token. This is what the CLI, the MCP server, and your own scripts use.

Either way, the request acts as a user with their role in the org named in the URL path. Most endpoints are org-scoped: /orgs/:orgId/monitors, /orgs/:orgId/channels, /orgs/:orgId/rules, and so on.

build on it

If you'd rather not hand-roll HTTP, a Go client wraps the same API:

import "pngr.dev/go-client"

c := pngr.NewClient(pngr.WithToken(os.Getenv("PNGR_TOKEN")))
monitors, err := c.Monitors.List(ctx, orgID)

For one-off scripting, the CLI emits --output json and --output yaml on every command — often the fastest path to a working integration.

a note on origins

In the browser, the app only ever talks to its own origin — all /api/* requests are proxied server-side to the backend. That's what keeps the HttpOnly session cookie working and OAuth round-trips landing on the right host. It doesn't affect you as an API consumer: point your token at the backend's /v1 base URL directly (the CLI's api_url config), or at the app origin's /api if you're calling from the same host.