For the complete documentation index, see llms.txt.The Maneuver API exchanges stored spacecraft maneuver records through CCSDS OCM at
https://api.valar.space. Import OCM files, export selected records or time ranges, and
delete records when needed. Each record belongs to one spacecraft and contains burn segments.
Importing a record stores data in VALAR; it does not uplink a command to a spacecraft.
API contract
Download the standalone OpenAPI contract to generate a client or pin an integration. Itsinfo.version identifies the contract version.
The complete live customer API is available at
/api-docs/mintlify, with the maneuver version in
x-valar-maneuver-api-version and each operation’s version in x-valar-contract-version.
The three public operations are:
The maneuver planner, approval, and orbit-raise workflows are available
in the application and are outside this published API.
Authenticate a mission-control integration
Use an API key issued for your organization and granted the Operations environment. SendAuthorization: Bearer $VALAR_API_KEY on every request. The key inherits its
owner’s resource permissions, and requests are recorded in the API-key usage audit log.
Organization and environment are derived from authentication and the route.
Look up the VALAR spacecraft ID before making maneuver requests:
SPACECRAFT_ID below. Names, NORAD IDs, COSPAR IDs, and external keys
are lookup filters, not substitutes for the VALAR spacecraft ID in export or delete requests.
Identify records through OCM
Use an OCM export to inspect stored burn definitions. Select knownMAN_ID values or export
a spacecraft/time range using the examples below.
OCM MAN_ID is the stable maneuver identity within its spacecraft, with a maximum length of
63 characters. An editable display name is not a substitute for that identity.
Address a deletion by maneuverId plus spacecraftId; URL-encode path values when necessary.
Resolve conflicts
Imports must not overlap another stored maneuver on the same spacecraft. The check uses each record’s enclosing start-to-end interval, including gaps between segments. Adjoining intervals may touch: a record ending at 12:01 may be followed by one starting at 12:01. Records on different spacecraft do not conflict with each other. Duplicate identities and overlaps with stored records return 409MANEUVER_CONFLICT.
Use the reported identities to export and inspect conflicting records, then decide which records
to retain or explicitly delete. No record is automatically merged, shortened, replaced, or
deleted. A conflict may be outside your current export window. Records with existing overlaps
remain exportable and deletable. Computation results retain their captured maneuver data;
new computations use the current records.
Delete a record
Correct a stored maneuver
- Export and inspect the record, retaining the file if you need a copy.
- Prepare corrected OCM that satisfies the import requirements.
- Explicitly delete the stored record and confirm that deletion succeeded.
- Import the corrected file and check its result:
Import and export OCM files
Import adds records from CCSDS OCM files:files part for several files. spacecraftId is optional when file
metadata resolves the target unambiguously. Files require thrust, ISP, and physical wet mass;
see OCM import requirements. MAN_BASIS is optional
format metadata and has no effect on stored-record behavior. Exports omit it. OCM MAN_ID
remains the stable identity, even after the editable name changes.
Each file commits atomically and independently. 200 means every file succeeded; 207
contains per-file successes and failures, including ambiguous targets. Inspect successCount,
failureCount, and results. An all-ambiguous batch also returns 207. If every file fails
without ambiguity, the request returns an error, such as 400 for invalid input or 409 for a
stored-record conflict. A failed file adds none of its records; successful files remain saved.
Reimporting an existing MAN_ID fails. To submit a correction, follow
Correct a stored maneuver.
Optional X-Content-Hash and X-Resolution-Fingerprint headers bind an import to a previously
inspected file. A stale preview returns 409 IMPORT_STALE_PREVIEW. Direct callers may omit
these headers. Submit preview-bound files individually rather than binding a multi-file batch
to one preview.
All exports use GET /operations/maneuvers/export. Export one record by supplying one
spacecraftIds value and one maneuverIds value, for example
/operations/maneuvers/export?spacecraftIds=SC-1&maneuverIds=BURN-001.
For selected IDs, use the collection GET with exactly one spacecraftIds value and 1–100
unique maneuverIds. Repeat the maneuverIds parameter for each identity; commas inside a
value are literal name characters, not separators. One ID produces text/plain OCM;
multiple IDs produce application/zip. Send these selections as query parameters with no request body.
endDate after startDate. One spacecraft produces OCM text; multiple spacecraft
produce a ZIP of OCM files. ID and time-range selection are mutually exclusive: do not send
time bounds with maneuverIds. Missing, empty, or mixed selections return 400. URI size limits
still apply; divide a large selection into smaller GET requests if its encoded URL is too long.
Integration software owns downstream submission and uplink procedures.
Handle errors and retries
Resource, validation, and permission errors use VALAR’s shared error envelope, includingtimestamp, status, error, message, and path, with structured details where available.
Use the machine-readable error token and HTTP status instead of parsing prose messages.
GET exports can be retried with bounded backoff. Import has no idempotency-key contract: if a
connection drops after submission, export the affected identities or time range and inspect
the stored data before repeating the write. Do not retry successful files in a 207 batch.
After an uncertain DELETE result, verify the record’s state through export before importing
a correction; distinguish a missing record from authentication, permission, or transport errors.