Security & account
How we protect your account and data: API key storage, HTTPS, email verification, password reset, two-factor authentication (2FA), and retention.
API key storage
Store API keys in environment variables or server-side config only. Never expose them in client-side code or commit them to source control. Use LOGGER_API_KEY in your server or build environment; the Node SDK uses the hosted ingestion URL by default, so LOGGER_API_URL is only needed for local or self-hosted—as in our examples/test-backend and examples/go.
LOGGER_API_KEY=lb_sb_xxxx# LOGGER_API_URL only for local / self-hostedHTTPS and retention
All API and dashboard traffic should use HTTPS. Log data retention depends on your plan and destination; see the dashboard and Terms of Service / Privacy Policy for details.
Email verification
After you sign up, we send a verification link to your email (when email is configured). You can sign in before verifying; your account shows as unverified until you click the link. Use the link in the email or request a new one from the dashboard if needed.
Forgot password
On the login page, use Forgot password? Enter your email; if an account exists, we send a reset link (when email is configured). The link expires after a short time. On the reset page, enter the token from the link and your new password (min 8 characters). Then sign in with your new password.
Two-factor authentication (2FA)
In the dashboard, go to Settings → Security. You can enable 2FA with an authenticator app (e.g. Google Authenticator, Authy). After you scan the QR code and enter a 6-digit code, 2FA is turned on. On future logins, after entering your password you will be asked for a code from your app. To disable 2FA, use Settings → Security and enter your password and current code.
API keys and dashboard auth
API keys (used for POST /v1/logs) are stored as SHA-256 hashes; we never store or log the plaintext key. Create and revoke keys in the dashboard; keep them in env vars, never in client-side code or source control. Dashboard sign-in uses password hashes (bcrypt) and optional 2FA (TOTP). Session tokens are JWTs with a limited lifetime.
Log data
Log messages and metadata are sanitized before storage: newlines and control characters are normalized, script tags are stripped, and size is capped. See the API reference for request limits and behavior.