Personal API tokens
Personal API tokens (PATs) authenticate scripts, CI pipelines and integrations against the ShxrkSystems API — no browser session needed.
Create one in the dashboard under Security → Sessions → API Tokens. Tokens can have an optional expiry (30/90/180/365 days or never) and are shown exactly once — store them like a password. We only store a SHA-256 hash; a leaked database never leaks usable tokens.
Using a token
Send it as a bearer token:
Authorization: Bearer sk_shx_<token>
curl -H "Authorization: Bearer sk_shx_..." \
https://api.shxrk.systems/api/v1/uptime/monitors
Token lifecycle
# Create — plaintext is returned exactly once
curl -X POST https://api.shxrk.systems/api/v1/user/api-tokens \
-H "Authorization: Bearer <session-or-token>" \
-H "Content-Type: application/json" \
-d '{ "name": "ci-pipeline", "expires_in_days": 90 }'
# → { "id": "...", "token": "sk_shx_...", ... }
# List (hashed, secrets never exposed)
curl https://api.shxrk.systems/api/v1/user/api-tokens -H "Authorization: Bearer ..."
# Revoke — takes effect immediately
curl -X DELETE https://api.shxrk.systems/api/v1/user/api-tokens/<id> -H "Authorization: Bearer ..."
Revoked and expired tokens return 401. last_used_at on each token shows when it was last used — a stale token you forgot about is visible at a glance.
What tokens can access
A PAT acts with your full user identity on the authenticated API surface — monitors, status pages, incidents, maintenance, agents, webhooks, event rules and more. Per-scope restriction (read-only tokens etc.) is on the roadmap; treat tokens as full-access credentials today.
Other credential types
- Heartbeat tokens (
hb_...) — authenticate only the heartbeat push endpoint of one monitor - API monitoring push keys — authenticate only metric pushes to one API monitor
- Game server push keys — same pattern for game server metrics
INTERNAL_API_KEY— service-to-service only (e.g. the Discord bot), never user-facing