API Introduction

VitalSentinel exposes a REST API that returns the same monitoring data the dashboard shows: uptime, SSL, RUM, CrUX, Synthetic Monitoring, Web Analytics, Google Search Console, Indexing Monitoring, robots.txt, sitemaps, alerts, notifications, and reports.

It is a separate surface from the one the dashboard itself uses. It has its own authentication (bearer tokens, never session cookies), its own frozen response schemas, its own error format, and its own OpenAPI document. That separation is the point: the dashboard's internal API changes whenever the dashboard changes, and your integration should not.

Base URL

https://app.vitalsentinel.com/api/public/v1

Every path in this documentation is relative to that base. https://api.vitalsentinel.com/api/public/v1 serves the identical routes on an alternate hostname, so moving between the two is a hostname swap and nothing else.

The OpenAPI document and the generated clients point at the application host, because that URL is correct in every environment including local development.

Reference documents

The OpenAPI document is unauthenticated and is the authoritative contract. Anything not in it is not promised. See Versioning and stability for what that guarantee covers.

The one call worth trying first

GET /health is unauthenticated, so you can confirm you are reaching the right host before you have a credential:

curl https://app.vitalsentinel.com/api/public/v1/health
# {"status":"ok"}

Available on every plan

API access is not a paid add-on and is not gated by plan tier, Free included. Protection comes from the shape of the rate limits and the credit allowance, not from feature gating.

Two things do scale with your plan:

• API credits per billing cycle. Every request costs credits, and cached answers cost zero. See API credits.
• How many live API keys one workspace may hold. The default is 10, which is generous for one key per integration plus one per CI pipeline.

Choosing a credential type

What the API does not cover

The surface is deliberately a subset of what the dashboard exposes. These gaps are decisions, not gaps waiting to be filled:

• Creating or editing workspaces and domains. Both are read-only through the API. Domain verification is coming, and an API-created domain would bypass it.
• Billing and subscription management. Excluded entirely.
• Creating or revoking credentials. A credential must not be able to mint another credential, so key management lives only in the dashboard.
• Google account connection. Connecting or disconnecting a Google credential is a dashboard-only flow.
• Individual visitor session records. RUM responses never include a session_id, at any scope. See Conventions.
• Anything the dashboard itself does not expose. If a person cannot do it in the app, a credential cannot do it through the API.

Where to go next