API Keys
Use the right key for the surface. Publishable keys are for browsers; secrets stay on servers.
Key kinds#
- Publishable
pk_live_…— browser RUM ingest only. - Project secret
sk_live_…(no embedded id) — preferred for @mydle/logs and deploy hooks. Not a management API key. - Workspace ingest key
ik_live_<id>_…— logs ingest only, bound to a project. Create under Settings → API Keys (Log Ingestion Keys). - Workspace management key
sk_live_<id>_…— Bearer for/api/v1management REST. Optional project restriction is enforced server-side: when set at create time, the key cannot access other projects (including via path or queryprojectId). Distinct from compact projectsk_live_. - Logs source token
lt_…— per-source logs ingest (Logs → Sources). Still fully supported. - Tracing source token
tt_…— OTLP ingest only. - Legacy workspace API key
mydle_…— Bearer for/api/v1when entitled.
Set up, step by step#
Pick the key that matches the surface you are connecting. Secrets are shown once — copy them into a server-side secret store.
Step 1: Open API Keys
Go to Settings → API Keys. You will see Management API Keys (
sk_live_<id>_…for/api/v1) and Log Ingestion Keys (ik_live_…).Step 2: Create the right key
- New API key — management REST. Optionally restrict to one project at create time.
- New ingest key — logs ingest only; must be bound to a project.
- Browser
pk_live_…and projectsk_live_…secrets — from the Browser / project connect flows. - Per-source
lt_…/tt_…— Logs → Sources and Tracing → Sources & ingest.
Step 3: Store the secret
Copy the plaintext secret immediately. Afterwards only a masked prefix remains. Never put management, ingest, or
lt_/tt_tokens in browser bundles.Step 4: Verify with a call
For a management key, list projects. A
200with your workspace projects (or a single project for restricted keys) confirms the key works.curl -sS https://www.mydle.app/api/v1/projects \ -H "Authorization: Bearer $MYDLE_API_KEY"
Where to create#
Management and workspace ingest keys: Settings → API Keys. Project publishable/secret keys and per-source lt_ / tt_ tokens live on the project (browser / logs / tracing connect flows). Secrets are shown once on create.
Usage#
# Management REST (workspace or project-restricted sk_live_<id>_…)
Authorization: Bearer sk_live_<id>_…
GET /api/v1/projects
GET /api/v1/projects/{projectId}/monitors
# Logs ingest
Authorization: Bearer ik_live_<id>_…
Authorization: Bearer sk_live_<project-secret>
Authorization: Bearer lt_…
# Common errors
401 unauthorized — missing/invalid/wrong credential kind
403 forbidden — missing scope, plan gate, or project restriction
429 rate_limited — Retry-After + X-RateLimit-* headersSecrets are shown once on create or rotate, then only a masked prefix remains. Revoke immediately from Settings → API Keys. Endpoint map: API Reference.
Limitations
- Never embed secret or workspace API keys in client-side bundles.
- Plan gates still apply (for example API access, log management, tracing).
- Project-restricted management keys cannot call workspace-admin endpoints or create projects.
- Project-restricted keys pin list/search/aggregate responses to that project (logs, incidents, deployments, browser apps, status pages — workspace-null rows excluded). Trace list/detail/overview/service-map also include workspace-level traces with no
projectIdbecause OTLP ingest stamps the source's project (null = shared workspace collector). Those rows are not another project's id; other projects' stamped traces are never included. Prefer project-boundtt_sources when telemetry must stay private to one project. Workspace log retention cannot be changed with a project key.GET /api/v1/workspacereturns workspace identity (and billing when scoped) — not other projects' telemetry.