CLI, API & RPC — the three interfaces

OpenRemap is one engine with three surfaces. They are not three different products: they expose the same methods, the same input schema, and the same JSON-safe results — only the way you reach them differs.

The same action, all three ways:

# 1. CLI — run the command
openremap identify stock.bin

# 2. Python API — call the method in-process
python -c 'import openremap.api as api; print(api.call("identify", {"path": "stock.bin"}))'

# 3. RPC — send a JSON-RPC request to the stdio server
echo '{"id": 1, "method": "identify", "params": {"path": "stock.bin"}}' \
  | python -m openremap.api.transport.stdio

All three print (or return) the same identification result.

How they relate

The engine is organised in layers:

• openremap.core.* — the internal engine: extractors, services (identify, maps, checksums, recipes), the Rust core.
• openremap.api.* — the canonical public surface: a registry of methods with typed input schemas. Methods come in three kinds — command (atomic), composite (orchestrated), workflow (declarative TOML pipeline).
• The CLI, the TUI, and future apps (Studio, Harness) are shells on top: they call the same engine, so behaviour and results never drift between surfaces.

One consequence worth remembering: defaults and validation live in the method schema, not in the client. A method that requires path rejects a call without it no matter which surface you used — ask the registry what it expects via list_methods.

Which one should I use?

Wait — "workflow" appears twice

Two unrelated things share the word workflow:

1. openremap workflow — a CLI command that prints a plain-English step-by-step guide in your terminal. Start here if you are new.
2. A workflow method kind — a declarative, code-free .toml pipeline that chains API methods (e.g. identify both binaries, then cook). It has nothing to do with the terminal guide.

The API-side workflows (declarative .toml pipelines) are documented on the API workflows page.

Where to go next