Account & Billing
REST API reference
Everguardly v1 REST endpoints — authentication, rate limits, monitors, incidents, clients.
Updated 2026-05-26 · 1 min read
Everguardly exposes a small REST API for the actions agencies actually script: list monitors, create monitors, fetch incidents, and check API health. Every endpoint lives under /api/v1.
Authentication
Auth is Bearer token. Provision a key in Settings → API keys (owner only). The token is shown once and never displayed again — persist it to your CI's secrets manager immediately. Send it as:
curl https://everguardly.com/api/v1/me \ -H "Authorization: Bearer eg_live_..."
Every request is scoped to the org that created the key. Revoking a key from the dashboard immediately invalidates it.
Rate limit
60 requests per minute per key. Exceeded calls return 429 with X-RateLimit-Reset indicating the unix timestamp when the bucket resets. Successful responses include X-RateLimit-Limit and X-RateLimit-Remaining for backoff calculations.
Endpoints
GET /api/v1/me
Sanity check — returns the org your token belongs to plus the key id.
{
"data": {
"org": { "id": "uuid", "name": "Acme", "slug": "acme" },
"role": "owner",
"apiKeyId": "uuid"
}
}GET /api/v1/monitors
Lists monitors. Query parameters: status=up|down|paused|pending, client=<clientId>, limit=N (max 500).
POST /api/v1/monitors
Creates a monitor. Body: name (required), url (required, must start with http:// or https://), type (http | https | tcp | ping; defaults to http), intervalSeconds (60 / 300 / 900 / 3600), clientId, tags array, regions array (eu-central and/or us-east).
curl -X POST https://everguardly.com/api/v1/monitors \
-H "Authorization: Bearer eg_live_..." \
-H "Content-Type: application/json" \
-d '{"name":"Marketing site","url":"https://example.com","intervalSeconds":300}'GET /api/v1/monitors/[id]
Returns the full monitor record including region affinity, tags, and pause state.
DELETE /api/v1/monitors/[id]
Permanent delete (cascades checks, incidents, alerts). Use with care — there is no soft delete in V1.
GET /api/v1/incidents
Lists incidents in your org. Filters: status=open|resolved, client=<id>|none. Open incidents are always sorted first.
GET /api/v1/incidents/[id]
Returns one incident plus its full event timeline (opened, scope_changed, acknowledged, note, alert_sent, resolved) and every alert delivery row that fired for it.
GET /api/v1/clients
Lists clients in your org with status page state.
Response envelope
Success bodies are { "data": ... }. Errors are { "error": { "code", "message" } } with a meaningful HTTP status: 400 bad_request, 401 unauthorized, 404 not_found, 429 rate_limited, 500 internal. Cache-Control is no-store on every response.
OpenAPI
The machine-readable schema is at /api/v1/openapi.json — point your tooling (Postman, Insomnia, openapi-generator) at it directly.
Push vs pull
For event-driven workflows (alert your PagerDuty / Slack on incidents), prefer webhooks over polling. Webhooks fire within seconds of an incident state change and carry the same payload shape as the equivalent GET endpoint.
Need something this doesn't cover? Email hello@everguardly.com — we'll write the doc.