API Overview

StatusRadar exposes a versioned REST API for programmatic access to monitoring data plus ingestion endpoints for probes, server agents, and observability telemetry. This page lists the full API surface grouped by family, with the authentication scheme each family uses.

Base URLs

All endpoints live under the /v1 prefix. The host depends on the family:

API version

Current API version: v1. The version is part of the URL path. Future versions ship under new prefixes (v2, …) while v1 stays stable.

Authentication at a glance

Auth schemes differ by family. Do not assume everything is a Bearer token.

See API Authentication for token types and management.

Request and response format

The API follows REST conventions:

• GET — retrieve resources
• POST — create resources / submit data
• PUT — update existing resources
• DELETE — delete resources

POST and PUT requests send a JSON body and must include:

Content-Type: application/json

Successful requests return JSON with HTTP 2xx. Errors return a 4xx/5xx status with a JSON body:

{
  "error": true,
  "message": "Resource not found",
  "status": 404
}

Common status codes: 400 bad request, 401 unauthorized, 403 forbidden, 404 not found, 422 validation failed, 429 rate limited, 500 server error.

Public API

No authentication. Read-only access to published status data.

GET /v1/status/{slug}              # Public status-page payload
GET /v1/monitors/{id}/uptime       # Public uptime for a monitor

curl https://api.statusradar.dev/v1/status/my-status-page

User API

Requires a user API token (Authorization: Bearer <token>). Generate one at Dashboard → Settings → API. Scoped to the resources your account (and team) owns.

Monitors

GET    /v1/monitors                # List monitors
POST   /v1/monitors                # Create a monitor
GET    /v1/monitors/{id}           # Get a monitor
PUT    /v1/monitors/{id}           # Update a monitor
DELETE /v1/monitors/{id}           # Delete a monitor
GET    /v1/monitors/{id}/checks    # Recent check results
GET    /v1/monitors/{id}/metrics   # Performance metrics
GET    /v1/monitors/{id}/uptime    # Uptime summary

curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://api.statusradar.dev/v1/monitors

Incidents

Read-only via the API.

GET /v1/incidents                  # List incidents
GET /v1/incidents/{id}             # Get an incident

Status pages

Read-only via the API.

GET /v1/status-pages               # List status pages
GET /v1/status-pages/{id}          # Get a status page

Probe API

Used by distributed Python probes. Authenticated with a probe token (Authorization: Bearer <token>). Reachable on both api.statusradar.dev and statusradar.dev.

POST /v1/probe/check-result        # Submit a check result
GET  /v1/probe/get-checks          # Fetch checks assigned to this probe
POST /v1/probe/heartbeat           # Report probe liveness

Agent API

Used by the StatusRadar server agent. Authenticated with an agent token (Authorization: Bearer <token>).

POST /v1/agent/register            # Register an agent
POST /v1/agent/metrics             # Submit server / plugin metrics
GET  /v1/agent/config              # Fetch agent configuration

See Agent installation and Agent configuration.

OTLP ingestion

Backend observability telemetry. Send to otlp.statusradar.dev with an app token in the X-App-Token header. Create an app and token at Dashboard → Observability.

POST /v1/traces                    # Spans
POST /v1/logs                      # Log records
POST /v1/metrics                   # Metrics

curl -X POST https://otlp.statusradar.dev/v1/logs \
  -H "X-App-Token: YOUR_APP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

See OTLP overview.

RUM ingestion

Real User Monitoring from the browser SDK. Send to rum.statusradar.dev with the app key as the api_key query parameter.

POST /v1/ingest?api_key=YOUR_API_KEY   # Browser RUM events

Event types include vital, pageload, error, console, click, network, and replay_chunk. See RUM overview.

Rate limiting

API requests are rate limited per token/IP. When exceeded, the API returns HTTP 429 with a retry_after value. Cache responses and back off exponentially on retries.

Next Steps

• API Authentication — token types, scopes, and security
• OTLP overview — backend traces, logs, and metrics ingestion
• RUM overview — browser real-user monitoring
• Agent installation — set up the server agent
• Observability overview — apps, domains, and quotas