These endpoints read authored content: the same records the editors in Hydra Studio
open, and the same ones the game plays from. All of them are GET and need no
token. For the port, the paths and the token, see Web API; for changing content, see
Web API Writes.
What comes back
- The whole collection (
/api/factions) is usually one JSON
object keyed by each record's name or id: { "Alliance": {...}, "Daichi": {...} }.
The tables below say where a collection is an array or a wrapper instead.
- One record (
/api/factions/Daichi) is the record itself.
If there is no such record, the body is empty.
- The
-list endpoints return only the keys. Use them to fill
a picker; they are far smaller than the full collection.
- What you read is the merged view. When two active modules define the
same name, the one loaded later wins, and that is the record the game uses. Every record
carries
ModuleID, the module it came from. See Modules for how layering
works.
The Saved by column says how each kind is changed: through this API (see
Web API Writes), by Hydra Studio's editors, or not at all.
Missions and story
| Endpoint | Keyed by | Returns | Saved by |
missions | id | Full mission definitions: objects, objectives, events, waypoints, options, script. | Editor |
missions-list | - | Mission ids only. | |
campaigns | id | Campaigns and their ordered steps. | Editor |
encounters | name | Spawnable encounter groups. | API |
dialogs | dialog id | Full dialog trees. A translated dialog's key ends in its language, such as -fr. | API |
dialogs-list | - | Dialog keys only. | |
pedia/{module}/{id} | id | One in-game encyclopedia entry, with its text. Name the module: without it the server looks in its default module only. | API |
pedia-list | id | The encyclopedia index. | |
pedia-search/{text} | - | Entries matching the text. | |
module-events/{module} | name | Module-level events of that module and the modules it is built on, the module's own winning. | |
Ships and equipment
| Endpoint | Keyed by | Returns | Saved by |
vessel-classes | name | Vessel classes: hull, decks, hard points, roles, cameras. See Vessel Classes. | Editor |
hull-types | name | Hull types with their damage and mass profile. | Not saved |
components | id | Component definitions. See Components. | API |
component-parts | id | Upgrade parts: what slot they fill and what they improve. | API |
ordnance | name | Munition types. | API |
models | name | 3D models and their materials. The list leaves out each model's mesh layout; ask for one model to get it. See Models Textures And Shaders. | API |
commodities | name | Tradeable commodities. | API |
commodities-list | - | Commodity names only. | |
companies | id | Manufacturers and operators. | API |
The world
| Endpoint | Keyed by | Returns | Saved by |
maps | id | Full map definitions: systems, planets, locations, environment. Large. See Map Editor. | Editor |
maps-list | - | Map ids only. | |
factions | id | Factions and how each stands with the others, from -1 (at war) to 1 (allied). | API |
Roles, tasks and bots
| Endpoint | Keyed by | Returns | Saved by |
archetypes | name | NPC roles, as written and as inherited. Below. | Editor |
task-definitions | name | Authored task plans: the steps a ship works through. Below. | Editor |
bots | id | Pre-made characters a Game Master can seat on a player ship. Below. | Editor |
There is no endpoint for tactics.
archetypes (roles)
A role is built in layers: Pirate inherits from Raider and
Merchant, and much of what a pirate does is written in those. Each role comes
back with both halves, what it says itself and what its whole chain adds up to:
GET /api/archetypes/Pirate
{
"Name": "Pirate",
"ModuleID": "Horizons",
"Tags": ...,
"InheritNames": [ "Raider", "Merchant" ],
"Authored": { "Tasks": [...], "Reflexes": [...], "Bias": {...} },
"Resolved": {
"Chain": [ ..., "Raider", "Merchant", "Pirate" ],
"Unbound": [],
"Tasks": [...],
"Reflexes": [...],
"Bias": {...}
}
}
Chain is the order the layers are applied in, so when two layers set the
same task, the later one in the chain wins. Unbound names any parent that does
not exist. A misspelled parent does not stop a role from loading; it just adds nothing, and
this is where it shows.
The whole collection is { "Archetypes": [...], "TaskTypes": [...], "Modules": [...] }:
the roles, every task type a role may name, and every module a role can be saved into.
Role names ignore case.
task-definitions (tasks)
One plan is Name, Description, ModuleID,
Loop, Focus and its Steps; each step has a
primitive (what the ship does), a target tag, a gate (conditions that end the step) and
actions to run on the way in and out. The whole collection is a wrapper that brings the
vocabulary a step is built from: TaskDefinitions, Primitives,
Tokens (targets that need no tag, such as home and
target), Flows, TaskTypes, Shadowed
(which built-in task types an authored plan replaces, and from which module) and
Modules. Plan names ignore case.
bots
The collection is { "Bots": [...], "Modules": [...] }, and unlike
everything else on this page it is not merged: it holds every module's own bots, each with
its ModuleID, so a bot that one module overrides appears once per module. Ask
for one id to get the bot the session actually uses. Which bots may sit in a given mission
is a live question; see mission-bots in Web API Live State.
Sound, effects and consoles
| Endpoint | Keyed by | Returns | Saved by |
sound-banks | id | The collection is { "Settings", "ModuleSettings", "Banks" }: playback defaults, each module's calibration, and the banks. See Sound Banks. | API |
effects | id | Effect banks, in the same wrapper. One bank can also be asked for by an alias. See Effect Banks. | API |
effect-renderers | - | Every effect renderer the consoles can load: Name, the ModuleID that supplies it, its Path, and Shadows, the modules whose copy it hides. | |
widget-sources | - | Every widget a screen can mount, in the same shape. See Widgets. | |
screens | - | Every registered console screen, always the whole set. See Consoles And Screens. | Editor |
input-actions | - | An array of bindable actions. Not merged: every module's own, each with its ModuleID. | API |
input-roles | - | An array of input roles (one per station) and their bindings, likewise per module. | API |
devices | number | Physical device bindings. | Editor |
shaders | - | Answers nothing at present. | |
Name lists
names-callsign, names-male, names-female,
names-surname, names-system,
names-system-suffix and names-vessel return the lists the game
draws generated names from, keyed by the name. Each can be written through the API.
Modules and packages
/api/modules returns every module the server has found, and
/api/modules/{id} one of them. Each carries its manifest — ID,
Name, Parent, Version, Priority,
Active, Description, EngineVersion — and how it
was installed: Packaged and PackageBuildDate for a
.hyd package, Signer (the fingerprint of the key that signed it),
WorkshopItem for one that came from the Steam Workshop, and
ScriptsBlocked when its mission scripts are being held back. The module's
content comes with it, so the answer is large.
Modules are saved by the module editor, and packages are built and imported there too;
the API does not build, import or publish them. A packaged module is read-only: every write
into it is refused. See Modules and Packaging Modules.
| Endpoint | Returns |
describe-schema | The kinds of content and the endpoint for each. With an id — a content kind such as components, a type name, or an enum name — the fields of that type: name, type, legal values, the default a save fills in when the field is left out, and notes on fields a save cannot carry. |
validate | Runs the same checks as the editor's Problems panel over every loaded module and returns { count, errors, warnings, problems }. Give a module id to see only that module's problems. Each problem has a Severity, a Message and a Location naming the module, document, section and field. |
files | Every file the server serves, with its kind, its module, its URL and where it lives on disk. |
model-providers | The AI model providers Hydra Studio's assistant can use and whether each is ready. It never includes a key. |
describe-schema and validate are the two to reach for when you
write content with your own tools: the first tells you what a record may contain, and the
second tells you what is wrong with what you wrote.
Other names
A few endpoints answer to a second name as well: componentparts,
vesselclasses, archetype, task-definition and
tasks, bot, and widgets for
widget-sources. These work for reads only; writes use the main name.