Utility & identity

GET /v1/me, /v1/regions, and /v1/health. The three calls that tell you the setup is right.

Three endpoints that don't do any work, but answer the questions you have when something isn't working: is my key good, where am I calling, and is the service up.

Identity

GET /v1/me HTTP/1.1
Host: REGION.api.lararouter.com
Authorization: Bearer $LARAROUTER_API_KEY

The first call to make in any new environment. It proves the key is valid, tells you which region answered, and reports your plan, permissions, retention window, completion window, and current rate limit budget. That is enough to diagnose most setup problems in one round trip.

Requires any valid key. No scope needed.

curl https://REGION.api.lararouter.com/v1/me \
  -H "Authorization: Bearer $LARAROUTER_API_KEY"

{
  "object": "identity",
  "key": {
    "id": "key_7Fq2",
    "name": "production",
    "type": "secret",
    "last4": "9c41",
    "scopes": ["batches:write", "files:write", "usage:read", "requests:read"],
    "created": 1754006400
  },
  "project": {
    "id": "prj_2mK9",
    "name": "Acme API",
    "plan": "pay_as_you_go"
  },
  "region": "REGION",
  "permissions": ["batches:write", "files:write", "usage:read", "requests:read"],
  "retention": {
    "requests_days": 90,
    "conversations_days": 90
  },
  "rate_limits": {
    "requests_per_minute": 3000,
    "remaining": 2998,
    "reset": 41
  },
  "batches": {
    "completion_window": "24h",
    "concurrent": 8,
    "max_lines_per_batch": 50000,
    "max_file_bytes": 209715200
  },
  "features": {
    "sso": false,
    "short_completion_window": false
  }
}

Prop

Type

Plan-dependent behaviour

retention, batches, and features are the fields worth reading programmatically. They tell you whether a 13-month audit query or a 4-hour completion window will actually do what you expect on this project, rather than failing once you've already built the file.

Regions

GET /v1/regions HTTP/1.1
Host: REGION.api.lararouter.com
Authorization: Bearer $LARAROUTER_API_KEY

Lists every region with its host and current status. Unlike the rest of the API this answers the same way from any region, so it's a safe way to discover hosts instead of hardcoding them.

Requires any valid key.

curl https://REGION.api.lararouter.com/v1/regions \
  -H "Authorization: Bearer $LARAROUTER_API_KEY"

{
  "object": "list",
  "data": [
    {
      "id": "us",
      "name": "United States",
      "host": "us.api.lararouter.com",
      "status": "operational",
      "current": false
    },
    {
      "id": "eu",
      "name": "European Union",
      "host": "eu.api.lararouter.com",
      "status": "operational",
      "current": true
    },
    {
      "id": "in",
      "name": "India",
      "host": "in.api.lararouter.com",
      "status": "degraded",
      "current": false
    }
  ]
}

status is one of operational, degraded, or maintenance. current marks the region that served this call.

Region names honour Accept-Language.

Health

GET /v1/health HTTP/1.1
Host: REGION.api.lararouter.com

Unauthenticated liveness for the region you're calling. Safe to point an uptime monitor at, and safe to call from anywhere, because it exposes nothing about your project.

curl https://REGION.api.lararouter.com/v1/health

{
  "object": "health",
  "status": "ok",
  "region": "REGION",
  "time": 1754150400
}

status is ok or degraded. A region that is fully down won't answer at all, so treat a connection failure as down rather than expecting a JSON body.

Health is not a substitute for /v1/me

/v1/health says the region is up. It says nothing about whether your key works, which is the more common failure. Probe /v1/me in deployment checks and /v1/health in uptime monitors.

Identity

Regions

Health

On this page