Authentication

pml_live_<lookupId>_<secret>
└────┬────┘ └────┬────┘ └───┬────┘
     │           │          └─ 32 base62 chars — the secret half. Never stored
     │           │             in plaintext; we keep only a SHA-256 hash.
     │           └─────────── 12 base62 chars — the lookup half. Indexed in the
     │                        database; used to find the row before verification.
     └─────────────────────── Static prefix. Lets us (and secret-scanners) tell at
                              a glance that a leaked string is a postme.live key.

Total entropy in the secret half is ≈190 bits. We do not need bcrypt or argon2 — those exist to defend low-entropy passwords; for cryptographically-random API keys a single SHA-256 round is the standard.

Use the standard HTTP Authorization header with the Bearer scheme:

GET /api/v1/channels HTTP/1.1
Host: postme.live
Authorization: Bearer pml_live_AbCdEf123456_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Workspace owners and admins manage keys at Settings → Developers:

• Create — give the key a human-readable name and pick an expiry (1 day / 7 days / 30 days / 90 days / never). The full token is shown once. Copy it then.
• Rotate — there is no in-place rotation. Create a new key, swap your config, then revoke the old one.
• Revoke — instant. The next request with that key will return 401 unauthorized.

v1 issues a fixed scope set per key. Future versions will let you pick a subset at create time.

Every authenticated request writes an audit row to api_request_log with:

• API key id (never the secret)
• HTTP method & path
• Response status code
• Caller IP (first hop of X-Forwarded-For) and User-Agent
• Idempotency-Key (when present)
• Server-side request duration in milliseconds
• Truncated error message when the response was a 4xx/5xx