Health Endpoints

Three endpoints report whether the API is up, whether it is ready to take traffic, and whether the process is alive.

They are not under /api/v1, and they take no API key

The health paths are served at the root of the API, outside /api/v1, and they are the only paths excluded from the API-key security scheme. Sending a key is harmless; omitting one changes nothing. Because of that, a 200 from any of them says nothing at all about whether your credentials are valid — use an authenticated endpoint for that.

Which one do I call?

Question	Endpoint	Notes
Is the API up, and which environment is this?	GET /health	Reports environment; the fastest way to tell test from production
Should this instance receive traffic?	GET /health/ready	200 when ready, 503 when not. Wire load balancers and uptime monitors here
Is the process alive?	GET /health/live	Always 200. Wire container orchestrator liveness probes here

GET /health

Basic health check. Unauthenticated.

curl -X GET https://app.goroute.ai/peppol-api/health

{
  "status": "healthy",
  "version": "1.0.0",
  "environment": "production",
  "timestamp": "2026-08-06T06:09:57.050723"
}

Field	Meaning
status	"healthy"
version	API version
environment	Which environment this base URL and deployment resolve to
timestamp	Server time the response was generated

Use environment to confirm which environment you are talking to before you go live. It is the field the Environments page tells you to check.

GET /health/ready

Readiness. Answers 200 when ready and 503 when not ready — a probe that always returned 200 could never take a half-initialised instance out of rotation.

curl -X GET https://app.goroute.ai/peppol-api/health/ready

{
  "status": "ready",
  "version": "1.0.0",
  "environment": "production",
  "checks": {
    "database": "connected",
    "redis": "connected"
  },
  "timestamp": "2026-08-06T06:09:19.797475"
}

Field	Meaning
status	"ready" or "not_ready"
version	API version
environment	Which environment this deployment resolves to
checks.database	"connected", or an error string when the database check failed
checks.redis	"connected", "not_checked", or an error string
timestamp	Server time the response was generated

Redis is advisory; only the database gates readiness

A Redis failure degrades rate limiting but does not make an instance unready. checks.redis can therefore report an error string while the endpoint still answers 200 with "status": "ready". Do not alert on checks.redis alone, and do not treat a 200 as proof that Redis is healthy. Readiness is decided by checks.database and nothing else.

Behaviour change

This endpoint previously answered 200 in every case, including when the database check failed. It now answers 503 when it is not ready. If you wired a load balancer, an uptime monitor or an orchestrator readiness probe against the old behaviour and treated any response as healthy, revisit it — instances will now be pulled from rotation when the database check fails, which is the intended behaviour.

GET /health/live

Liveness. Always 200.

curl -X GET https://app.goroute.ai/peppol-api/health/live

{
  "status": "alive",
  "timestamp": "2026-08-06T06:09:20.524903"
}

It deliberately runs no dependency checks: reaching the handler proves the process is serving. Failing a liveness probe because a dependency is merely not ready yet would restart-loop otherwise-healthy instances, and that judgement belongs to /health/ready.

Recommended wiring

Consumer	Endpoint	Treat as failure when
Load balancer target group	/health/ready	non-200
Uptime / status monitoring	/health/ready	non-200
Container orchestrator liveness probe	/health/live	non-200
Environment confirmation in a deploy script	/health	environment is not what you expected

Related

• Environments — confirming test versus production
• First API Call — where /health fits in the first few requests
• Support — diagnosing an authentication problem, which these endpoints cannot do for you