Discover and use the AMM REST API

Discover your running server#

AMM exposes the same server services used by the application through REST. The running server generates its operation catalogue and OpenAPI 3.1 from registered routes and declared JSON contracts. Use that live catalogue for current payloads instead of copying a fixed endpoint list from an older guide.

Set the base URL to the API selected by your app. A standard local installation uses http://127.0.0.1:5100; your server can use another port or authenticated HTTPS. These read-only examples assume the documented loopback mode:

curl --fail-with-body http://127.0.0.1:5100/api/catalogue
curl --fail-with-body http://127.0.0.1:5100/api/catalogue/openapi.json -o amm-openapi.json
curl --fail-with-body http://127.0.0.1:5100/api/live/venues

Open /api/catalogue/docs on that API origin for the searchable browser and OpenAPI download. On an authenticated installation, enter the bearer credential in the browser's token field; it stays in page memory. Do not place a token in a URL or publish an authenticated request transcript.

Understand authentication#

There are two listener modes. LoopbackOnly uses HTTP on localhost/a literal loopback address. TlsBearer requires HTTPS and a valid bearer credential for protected operations. Remote plaintext access is unavailable. Host and browser Origin validation apply independently of provider credentials. A valid Alpaca key or cTrader token does not authenticate a request to AMM itself.

Use your installation's supported protected credential handling for scripts and clients. AMM CLI tools accept owner-only token files over HTTPS. Keep API tokens and provider secrets out of checked-in examples, screenshots and result artifacts. If an API call gets 401/403, inspect the AMM listener/token/Host/Origin boundary before changing broker credentials.

Read an operation before invoking it#

Search by method, path, tag or summary. Inspect path/query/header fields, required JSON members, defaults, accepted media types, response variants and error statuses. The catalogue exposes metadata completeness flags so an undeclared future contract cannot look complete silently. Its route inventory does not prove that every operation is headless or that a broker supports every action.

For example, GET /api/algorithms discovers the loaded algorithm catalogue; GET /api/plugins reports loaded plugin state; GET /api/live/venues reports provider roles/readiness. A generic provider entry can describe a broad adapter interface, so read its restrictions. Massive remains a data-only feed even if a generic role flag appears broad; IB futures/options execution remains unsupported.

Follow asynchronous job lifecycles#

Backtests, strategy optimizations, coordinated batches, walk-forward analyses and downloads can return an accepted job ID before work completes. Save that ID. Poll the operation's documented status endpoint or consume its WebSocket updates, then fetch results only after its terminal state. A successful submission is not a successful run.

Inspect per-symbol or per-child outcomes for batch/download jobs. A completed container can include failed children. Cancellation also has its own status and provider restrictions; cancelling an accepted job does not erase artifacts already written. Some operations retain their own durable results while others expose process-local activity. Read the operation's retention contract before building unattended recovery around it.

Use exact result/export routes from OpenAPI. Available surfaces include backtest orders/trades/bars and comparisons, optimization analysis/artifacts, walk-forward analysis, replay trade CSV/summary text, live audit reports and screener CSV. Binary responses have their declared media type; do not parse every successful response as JSON.

Headless operations and connected UI#

Server calculations, history acquisition, catalogue reads and many live controls can work without the desktop. Saved workspace state, chart appearance, native windows, dialogs and mounted widget actions belong to the connected application. Use /api/ui/commands to discover typed desktop commands and /api/ui/controls for the actual currently mounted targets.

A desktop action returns a correlated outcome: completed, failed, scheduled, timeout or no-ui. scheduled can mean a server connection switch was queued; verify state at the target server. timeout means no acknowledgment arrived in time, not proof that nothing happened. Rediscover and read state before retrying a mutation. See UI Command Bus.

Preserve execution safety and identity#

Live trading uses explicit account/feed/instrument graphs, preflight and confirmation. Exports/imports omit credentials and old approvals. Loading a saved configuration does not authorize LIVE trading. Role-specific symbol aliases retain the stable strategy identity while each connection uses its exact provider/account contract. No REST or MCP call should assume automatic FX conversion or universal contract equivalence.

Credentials managed through /api/credentials remain write-only. Profile/origin binding, revisions and explicit removal protect the same backend state used by the UI. Read redacted status to verify configuration rather than requesting a secret value back.

Build an integration that survives updates#

Fetch OpenAPI and discovery at deployment or startup, record the server version, and validate required operations before enabling mutations. Retain operation IDs and response status alongside your own job correlation. Handle null/unknown figures explicitly. Follow paginated lists and continuation cursors; short snapshots are not full ledgers.

After a software update, refresh schemas and the loaded plugin/venue catalogue. Add a small read-only smoke check, then a controlled Simulation/Paper workflow for any execution integration. Source-contract compatibility, successful HTTP transport and actual broker acceptance are separate checks. MCP provides the same discovery through generated tools when an agent client is more convenient.