Docs
API endpoints
Every route on the public API. Generated from the same list the product renders.
All routes are GET, all require a Bearer obsv_… key, and all are scoped to the
key's workspace. See authentication and errors first, and
the query grammar for the filter parameters.
GET/api/v1/runs
Same filters as the runs explorer. Paged via `nextCursor`.
Query parameters
rangefromtof.<dim>x.<dim>qsortlimitcursor
GET/api/v1/runs/:id
One run with its per-node breakdown.
GET/api/v1/runs/export
The same filter as CSV, for spreadsheets.
Query parameters
rangefromtof.<dim>x.<dim>qsortlimit
GET/api/v1/incidents
`?status=open` (default), `resolved`, or `all`.
Query parameters
statusrangefromto
GET/api/v1/workflows
Monitored workflows.
GET/api/v1/instances
Connected n8n instances and their health.
GET/api/v1/metrics
Prometheus scrape endpoint (text exposition).
Prometheus
/api/v1/metrics returns text exposition rather than JSON, and sets
cache-control: no-store.
scrape_configs:
- job_name: obsevo
metrics_path: /api/v1/metrics
scheme: https
static_configs:
- targets: ['app.obsevo.com']
authorization:
credentials: obsv_…It uses the same bearer authentication as everything else rather than being exposed on a separate unauthenticated port, because these gauges carry workflow and instance names, which are customer data.
No OpenAPI document yet
There is no openapi.json published. The response shapes are defined as schemas
in the codebase, but the handlers do not currently validate against them at the
boundary, so a generated document would be describing intent rather than observed
behaviour. Publishing one that is subtly wrong is worse than not publishing one.
If you want it, ask — it is a reasonable thing to want and the schemas are most of the work.