Health and uptime

The public /health endpoint — response shape, what it tells you, and how to monitor the API from your side.

Updated 2026-06-10

The Customer API exposes a public, unauthenticated health endpoint:

GET /api/v1/health

Response shape:

{
  "data": {
    "status": "ok",
    "db_latency_ms": 7,
    "version": "1.0.0",
    "commit": "abc1234..."
  },
  "request_id": "req_..."
}
  • HTTP 200 + status: "ok" — healthy.
  • HTTP 503 + status: "degraded" — the database ping failed.

Monitoring the API from your side

If your integration depends on the API, point your own uptime monitor at the health endpoint:

  • URL: https://fieldscroll.app/api/v1/health
  • Expect status 200 and the body keyword "status":"ok".
  • Alert after 2 consecutive failures rather than 1 — a single failed check is usually a transient network blip, not an outage.
  • Check from at least two regions if your monitoring tool supports it.

The endpoint is not rate-limited — it is unauthenticated and serves no customer data, so the per-key budget does not apply.

What a healthy response means

A 200 from /health confirms the API is routing requests and can reach its database. It does not exercise authentication — if you want end-to-end confidence, spot-check an authenticated read (for example GET /organizations) on a schedule with a low-privilege key.

During an incident

Requests may return 503 degraded from /health, or 500 / 502 from other endpoints. Retry idempotent operations with backoff (see rate limiting for the backoff recipe), and use idempotency keys on writes so retries cannot double-apply. Quote the request_id from any failed response when contacting support.