Skip to main content

Optimize

Planned API

There is no /optimize REST endpoint today; requests to it return 404. Optimization capabilities are available now through the console agent's tools. This page exists so integrators know what to use today and what is coming.

Available today: agent tools​

Optimization runs today as agent tooling in the console rather than behind a public REST endpoint:

  • Station selection: rank candidate ground stations for a fleet against geometry, weather, and capacity constraints.
  • Contact planning: choose contact windows across the fleet subject to elevation masks, station availability, and priorities.
  • Capacity allocation: distribute demand across available links and gateways and quantify the trade-offs.

The agent plans these as tool calls over the same physics-grounded engines that power simulations, so recommendations come with the geometry and link reasoning behind them, not opaque scores.

Start at the agent overview to see how to drive these capabilities conversationally today.

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 agent capabilities above.

The working sketch is a POST /optimize that accepts an objective, constraints, and candidates, and returns a ranked, explained result:

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

{
  "kind": "station_selection",
  "objective": "maximize_contact_minutes",
  "candidates": {
    "ground_station_ids": ["gs-madrid", "gs-svalbard", "gs-awarua"]
  },
  "constraints": {
    "min_elevation_deg": 10,
    "max_stations": 2,
    "horizon_hours": 24
  }
}

Expected semantics, all provisional:

  • kind selects the optimizer: station selection, contact planning, or capacity allocation.
  • Results would be ranked alternatives with the binding constraint named for each, not a single opaque answer, so operators can see why option two lost.
  • Long-running solves would follow the same asynchronous pattern sketched for simulations: 202 plus a poll.
  • 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 optimization results in an automated pipeline before the REST endpoint ships, drive the console agent, or talk to us about the decision you are trying to automate.