Tooling overview
Everything on these pages is built against the real ConstellationOS API surface: POST /telemetry, GET /topology, GET /predictions, and the /health endpoints, authenticated with the x-api-key header. Each artifact encodes the actual limits and error envelopes the API enforces, so you can drop it into an integration and expect it to behave correctly under rate limits, batch caps, and partial failures.
What ships here:
| Artifact | Page | What it is |
|---|---|---|
| TypeScript client | SDK: TypeScript | Single-file, zero-dependency, fetch-based client to copy into your codebase |
| Python client | SDK: Python | Single-file client on requests with dataclasses and the same retry and batching semantics |
| Reference CLI | CLI | One vendorable Python file with health, topology, telemetry ingest, predictions, and smoke subcommands, suitable for cron and CI |
| Terraform examples | Terraform | Customer-side IaC: key storage in Secrets Manager, a scheduled telemetry ingester, and health monitoring with alarms |
| CloudFormation template | CloudFormation | The same two patterns as a single CFN template |
| Postman collection | Postman | Importable collection covering every endpoint, with variables for all three environments |
| OpenAPI document | OpenAPI | Contract-true OpenAPI 3.1 document for codegen and tooling |
Base URLs and auth
All artifacts default to production and take the environment as configuration:
- Production:
https://api.constellation.space - Development:
https://dev.api.constellation.space - Sandbox:
https://sandbox.api.constellation.space
Every request except /health* requires your tenant API key in the x-api-key header. Tenant identity derives from the key, never from the hostname.
Packaging status
Packaged npm and PyPI SDKs and an installed CLI binary are on the roadmap; the vendorable single-file artifacts on these pages are the supported equivalents today. They are intentionally small enough to copy, review, and own inside your repository.