Skip to main content

Simulations

Planned API

There is no /simulations REST endpoint today; requests to it return 404. Simulation capabilities are fully available now through the console and its agent. This page exists so integrators know what to use today and what is coming.

Available today: console and agent​

The platform's simulation engines are deterministic and physics-grounded, and they run today behind the console and its agent rather than behind a public REST endpoint:

  • Orbit and Walker constellation synthesis: propagate a described constellation (planes, phasing, altitude, inclination) without needing live TLEs.
  • Gateway outage what-ifs: remove one or more gateways and quantify the coverage and capacity impact.
  • Deterministic rain: reproducible rain attenuation scenarios applied to link budgets.
  • Coverage, availability, and capacity analysis over a scenario horizon.

Deterministic here means what it does in simulation engineering: fixed inputs produce bit-identical outputs, so runs are reproducible, diffable, and safe to cite in operational decisions.

Where to use them now:

Planned REST shape​

Subject to change

Everything below is a design preview, not a contract. Field names, semantics, status codes, and the endpoint itself may change without notice. Do not build against it; build against the console and agent capabilities above.

The working sketch is a POST /simulations that accepts a declarative scenario and runs it server-side under your tenant:

POST /simulations
x-api-key: <tenant key>
Content-Type: application/json

{
  "kind": "gateway_outage",
  "scenario": {
    "gateway_ids": ["gs-madrid"],
    "start_utc": "2026-08-01T00:00:00Z",
    "duration_minutes": 90
  },
  "outputs": ["coverage", "availability", "capacity"]
}

Expected semantics, all provisional:

  • kind selects the engine: constellation synthesis, gateway outage, deterministic rain, or a composed scenario.
  • Runs would be asynchronous: a 202 with a run id, then a GET /simulations/{run_id} poll for status and results, since scenario horizons can take longer than a request timeout.
  • Determinism would be part of the contract: identical requests return identical results, and every run carries the engine version that produced it.
  • Auth, rate limits, and error envelopes would match the rest of the API: x-api-key, the documented 429 behavior, and {"error": "..."} shapes.

If you need simulation results in an automated pipeline before the REST endpoint ships, drive the console agent, or talk to us about your scenario; the engines exist today and the gap is only the public HTTP surface.