Skip to main content

​
Overview

The LogLife plugin registers six HTTP routes on the OpenClaw gateway:

​
Authentication

All endpoints require a Bearer token in the Authorization header:
The API key is configured in ~/.openclaw/openclaw.json under plugins.entries.loglife.config.apiKey. Generate one with:

​
Architecture

The API runs inside the OpenClaw gateway process — there is no separate service. The LogLife dashboard (hosted on Vercel) calls these endpoints through its own Next.js API routes, which add the Bearer token server-side. End users never interact with the plugin API directly.

​
User registration flow

In V1, registration happens before code verification:
  1. Dashboard calls /loglife/register with the user’s phone number
  2. Plugin adds the user to the multi-user config and updates gateway config
  3. Dashboard calls /loglife/verify/send with the same phone number
  4. Plugin sends a 6-digit code via WhatsApp
  5. User enters the code on the dashboard
  6. Dashboard calls /loglife/verify/check to validate the code
  7. The user can now send messages to the bot via WhatsApp
No gateway restart is required.

​
Security model

  • Bearer token auth on every request (timing-safe comparison)
  • Clerk auth on the Next.js proxy layer (only logged-in users)
  • Rate limiting on verification code sends (1 per phone per 60s)
  • Single-use codes deleted immediately after successful verification
  • 5-minute TTL on verification codes
  • Idempotent registration — registering an already-registered phone returns success without duplicating
  • Idempotent unregistration — unregistering an unknown phone returns removed: false
Documenting these endpoints publicly is safe because knowing the URL structure and parameters is useless without the API key, which is only stored server-side.