Alterscope serves the Developer API from two hosts. Both speak the same API — the same versioned paths, the same response envelope, and the sameDocumentation Index
Fetch the complete documentation index at: https://docs.alterscope.org/llms.txt
Use this file to discover all available pages before exploring further.
sk_live_ bearer authentication.
| Environment | Base URL | Use for |
|---|---|---|
| Production | https://api.alterscope.org | Live integrations and anything that depends on current data. |
| Sandbox | https://dev.alterscope.org | Pre-launch smoke testing and exploring the API shape. |
https://api.alterscope.org is the production base URL used throughout these docs and in the API reference.
Authentication
Both hosts use the same scheme — an API key (prefixedsk_live_) sent as a bearer token:
Browser WebSocket clients, which can’t set custom headers, pass the key via the ?token= query parameter instead. See Authentication for the full contract.
Whether a key issued for one environment is accepted on the other is not something to assume — confirm with the team before pointing a production key at the sandbox, or a sandbox key at production.
What the sandbox is for
The sandbox atdev.alterscope.org exists for pre-launch smoke testing — checking that your client connects, authenticates, and parses responses before you run against production.
Treat it as a non-production environment:
- Data may be less fresh. The sandbox can serve dev-indexed data, so values and timestamps may lag production. Branch on the
meta._agenticfreshness signal (see Freshness & staleness) rather than assuming a number is current. - No production SLA. Availability and latency on the sandbox are relaxed or best-effort. Don’t build anything that depends on its uptime.
Next steps
Authentication
Keys, headers, rotation, and revocation.
Scopes
The permissions a key can hold.