Your monitors belong in a repo, not a dashboard.

Every StatusKit account ships with a full REST API. Define each client's SSL, domain, uptime and keyword checks in a file, commit it, and apply it from CI. The console is just one view of the same API — nothing here is dashboard-only.

01Quickstart

Your api_key is your credential — there are no passwords. Grab it from the console (it's what you sign in with), or mint a fresh account straight from the API:

# One-time: mint an account + key (no password, the key IS the credential)
curl -s -X POST https://statuskit.app/api/accounts \
  -H "Content-Type: application/json" \
  -d '{"email":"you@agency.com","name":"Your Agency"}'
# => { "id": "...", "email": "...", "api_key": "sk_live_..." }   # store it now

Export it once and every call below just works:

export STATUSKIT_KEY="sk_live_..."

02Authentication

Send your key as a bearer token on every request. That's the whole auth model — a key in a header, exactly what a CI job or a Terraform-style workflow wants.

Authorization: Bearer $STATUSKIT_KEY

03Monitors

List them

curl -s https://statuskit.app/api/monitors \
  -H "Authorization: Bearer $STATUSKIT_KEY"

Create one

kind is one of http, ssl, domain, keyword. target is the URL or hostname (keyword uses url|word). interval_secs is an integer ≥ 60, default 300.

curl -s -X POST https://statuskit.app/api/monitors \
  -H "Authorization: Bearer $STATUSKIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Acme — store","kind":"ssl","target":"acme.com","interval_secs":300}'

Publish it to a status page

# Publish a monitor to its public status page:
curl -s -X PATCH https://statuskit.app/api/monitors/mon_123 \
  -H "Authorization: Bearer $STATUSKIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"public":true}'

04Monitoring as code

Here's the whole point. Keep your fleet in one version-controlled file — monitors.json — that is the request body:

{
  "prune": true,
  "monitors": [
    { "kind": "ssl",     "target": "acme.com",              "name": "Acme — SSL cert" },
    { "kind": "domain",  "target": "acme.com",              "name": "Acme — domain expiry" },
    { "kind": "http",    "target": "https://acme.com",      "name": "Acme — homepage", "public": true },
    { "kind": "keyword", "target": "https://acme.com|Cart", "name": "Acme — checkout alive" }
  ]
}

Reconcile the entire file in a single idempotent call to POST /api/monitors/sync. It figures out the diff for you — create the new, update the changed, delete anything prune:true and no longer in the file:

curl -s -X POST "https://statuskit.app/api/monitors/sync" \
  -H "Authorization: Bearer $STATUSKIT_KEY" \
  -H "Content-Type: application/json" \
  --data @monitors.json
# => { "counts": { "created": 4, "updated": 0, "unchanged": 0, "deleted": 0, "stale": 0 }, ... }
# Run it again unchanged   => everything "unchanged" (safe to re-run on every push).
# Edit a name / interval    => that monitor is "updated" — same monitor, history kept.
# Delete a line (prune:true) => that monitor is "deleted". Your file is the source of truth.

Now wire it to CI. A pull request to monitors.json becomes a reviewable, revertable monitoring change — exactly like any other code change:

# .github/workflows/statuskit.yml
name: StatusKit sync
on:
  push:
    branches: [main]
    paths: [monitors.json]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Reconcile monitors
        env:
          STATUSKIT_KEY: ${{ secrets.STATUSKIT_KEY }}
        run: |
          curl -sf -X POST "https://statuskit.app/api/monitors/sync" \
            -H "Authorization: Bearer $STATUSKIT_KEY" \
            -H "Content-Type: application/json" \
            --data @monitors.json

Drop your key in as the STATUSKIT_KEY repo secret and your clients' monitoring is version-controlled, diffable, and enforced on every push. That's the difference between "we have a dashboard" and monitoring as code. The monitors.json + workflow above are a complete, copy-pasteable starter — no extra tooling to install.

05Full endpoint reference

Every route takes Authorization: Bearer <api_key> except POST /api/accounts. All bodies and responses are JSON. Errors return { "error": "code", "message": "..." } with a matching HTTP status.