Pingvera exposes everything it sees: a REST API with an OpenAPI spec, an MCP server for Claude and Cursor, function calling for any LLM platform, status badges and widgets. Everything is read-only: an integration cannot break anything, even with a leaked token.
Authentication is an API token in the Authorization: Bearer pv_... header. Tokens are created in the dashboard (Settings → API), belong to your organization and get only the scopes you grant. The secret is shown once — we store only its fingerprint. A token can be revoked at any time.
Machine-readable spec — app.pingvera.com/api/v1/openapi.json (OpenAPI 3.0). Core endpoints:
curl -H "Authorization: Bearer pv_YOUR_TOKEN" \\ "https://app.pingvera.com/api/v1/incidents?status=open"
curl -H "Authorization: Bearer pv_YOUR_TOKEN" \\ "https://app.pingvera.com/api/v1/metrics/query?host=host_XXXX&metrics=cpu_pct,mem_used_pct"
Pingvera ships an MCP server (Model Context Protocol) — Claude Code, Claude Desktop, Cursor and any MCP client connect with a single command and can then answer questions like "which of my clients' sites are down right now?" or "what was this site's uptime over the past month?" — using the data from your account.
claude mcp add --transport http pingvera https://app.pingvera.com/mcp \\ --header "Authorization: Bearer pv_YOUR_TOKEN"
{
"mcpServers": {
"pingvera": {
"url": "https://app.pingvera.com/mcp",
"headers": { "Authorization": "Bearer pv_YOUR_TOKEN" }
}
}
}
LLM platforms without MCP support don't need it: any model with function calling works, and the functions are described straight from our OpenAPI spec. The pattern is simple: describe a function to the model (e.g. "get open monitoring events"), and when the model calls it — make a plain HTTPS request to the REST API with your Bearer token and return the response to the model. No Pingvera-side SDK required — just HTTP.
The public status page serves ready-made embeddable pieces — no tokens needed, they are public (disabled for password-protected pages):
<img src="https://app.pingvera.com/status/SLUG/badge.svg">
<script src="https://app.pingvera.com/status/SLUG/widget.js" async></script>
https://app.pingvera.com/status/SLUG/feed.xml
The status page itself can live on your own domain (status.your-client.com via CNAME, we issue the certificate ourselves) and can be password-protected — all configured in the dashboard, no code needed.
Pingvera's API and MCP server have no write operations, and the server agent is strictly one-way: it sends metrics and never accepts commands. This is not a missing feature — it is a principle: an integration with a leaked token can read your monitoring state, but it cannot stop a check, change a setting or touch a server. Revoke the token — access is gone.
Free plan — up to 5 sites with checks as frequent as 1 minute. Create a token in settings and connect your assistant in a minute.
Yes. A read-only REST API: checks, events, servers, metrics. Authentication via scoped API tokens, spec in OpenAPI 3.0 at app.pingvera.com/api/v1/openapi.json.
Via the built-in MCP server: run claude mcp add with an API token (read:monitoring scope) — and the assistant sees your organization's checks, events and uptime.
Yes, via function calling: describe the functions from the OpenAPI spec, and the calls go to the plain REST API with a Bearer token. MCP is not required for this.
No. The API and MCP are read-only, and the server agent is one-way. Even a leaked token cannot be used to stop checks or control a server; a token is revoked in one click.