Authentication

Every request carries Authorization: Bearer <key>. Two kinds of keys exist, for two places.

An API key must never reach a browser. Ephemeral keys exist so it never has to: an ephemeral key cannot send or read SMS, manage or read webhook endpoints and their deliveries, nor create other ephemeral keys.

API keysCopy Anchor Link

Create and revoke them in the dashboard. A key belongs to one company and acts on all of its lines. Everything it does is recorded as done by that key: created_by on every SMS and call reads { "type": "api_key", "id": "key_…" }.

BrowsersCopy Anchor Link

1. Your server calls POST /v1/ephemeral-keys with its API key, optionally restricted to one line. A restricted key sees only that line: GET /v1/lines returns it alone, its sessions ring only for it, and any other line, call or session answers not_found.
2. It hands the response to the browser: the key, its expiry, and the ICE servers WebRTC needs. They are the STUN and TURN servers of 06 Line; TURN credentials, when given, are made for this key and stop working when it expires.
3. The browser uses the key for 15 minutes, then asks your server for a new one. The SDK does this by itself.

curl -X POST https://api.06line.com/v1/ephemeral-keys \
  -H "Authorization: Bearer $SIXLINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"line_id": "line_01jbq5a3x9e2k7m4t6v8r0c1yb"}'

A WebRTC session or a call that is already open keeps going when the key expires: a three-hour call is never cut by it.

FailuresCopy Anchor Link

Rate limitCopy Anchor Link

Each key, API or ephemeral, may send 25 requests a second on average, and up to 100 at once. Beyond that, every route answers 429 rate_limited with retry_after_ms in the error and a Retry-After header (in seconds): wait that long, then retry.