Skip to content
BoringKit

Authentication

Authenticate with bearer keys and retry safely.

Use API keys for server-to-server requests. Browser sign-in uses account sessions for billing, key management, and supported account-only features. Never place API keys in client-side code.

Headers

Example
Authorization: Bearer $BORINGKIT_API_KEY
Content-Type: application/json
Idempotency-Key: stable-key-for-mutation-retry

Request pattern

Example
GET  https://api.arconath.com/boringkit/v1/tools
GET  https://api.arconath.com/boringkit/v1/tools/{slug}
POST https://api.arconath.com/boringkit/v1/url-metadata
POST https://api.arconath.com/boringkit/v1/jobs

Key versus session auth

API keys

Use bearer keys from trusted servers, workers, CI jobs, and back-office automations. Keys authorize API requests by scope.

Account sessions

Use browser sign-in for Account, billing, API key management, and supported account-only flows. These flows are tied to the signed-in user plan.

No browser keys

Do not embed API keys in frontend code, mobile apps, public notebooks, or shared browser snippets. Proxy those calls through your own server.

Local development

Local web can start production auth and return to localhost. Use a local callback URL only for your own account, and keep test keys separate from production job keys.