Skip to main content

Platform API Contract

This page defines which HyperionX code and integration surfaces public developers can depend on. It is a status and compatibility boundary, not a dump of internal desktop classes.

The latest signed public baseline recorded by the project changelog is HyperionX 1.1.12.0. The reviewed source also contains a direct SDK runtime adapter, but that adapter remains Preview until it has a frozen public compatibility contract and is verified in the exact installed build. Current 1.1.14 development-only behavior is not part of this baseline unless labeled explicitly.

Status Definitions

StatusContract
CurrentShipped in the reviewed release and documented for the stated public use.
PreviewImplemented or present in the active development tree, but packaging, compatibility, onboarding, or safety behavior is not yet a stable public contract.
InternalUsed by HyperionX itself; third-party code must not depend on it.
UnavailableNo supported public workflow exists.
RoadmapDirection only. No callable contract is promised.

Public Surface Map

SurfaceStatusPublic boundary
Generated HyperionX.Custom script runtimeCurrentEstablished 1.1.12 contract for Code Lab indicators and strategies, including the documented opt-in V2 facade.
Add-ons and chart render interfacesCurrent, narrowUse only the documented lifecycle/context or render-context members. Desktop windows and view models remain Internal.
Custom bar and research extension familiesPreviewProduct-owned runtime/default work is recorded in signed release 1.1.11 and later. This audit did not independently test the distributed MSI; verify the target build and first-launch discovery.
HyperionX.SDK.dll as a reference assemblyCurrentCode Lab can reference the assembly. Reference availability alone does not guarantee runtime activation.
HyperionX.SDK runtime host adapterPreviewPresent in the reviewed source and wired into its build/runtime generation path. It is not a stable public 1.1.12 authoring contract.
Local Desktop HTTP APIPreviewLoopback-only, token-authenticated, capability-discovered interface. Public token onboarding and schema stability are incomplete.
Agent Builder context/profile modelPreviewIn-app profile filtering and advisory configuration. It is not a standalone SDK or a per-token API scope.
Provider adapters and desktop servicesInternalDo not reference provider, WPF, controller, database, licensing, or build-service implementations.
Managed Rion cloud desktop bridgeInternalNot a third-party integration endpoint.
Marketplace packages and follower APIsInternal / UnavailableNo supported public publishing, package-install, or follower-routing contract.
hx command-line interfaceUnavailable / RoadmapNo supported CLI ships with this release.

Established Code Lab Contract

The source-recorded HyperionX 1.1.12 contract builds one custom project rooted at:

%USERPROFILE%\Documents\HyperionX\Bin\Custom
ExtensionNamespacePublic baseStatus
IndicatorHyperionX.Custom.IndicatorsIndicatorCurrent
StrategyHyperionX.Custom.StrategiesStrategyCurrent
Add-onHyperionX.Custom.AddonsAddonBaseCurrent, narrow
Bar typeHyperionX.Custom.BarTypesDocumented bar-type basePreview
OptimizerHyperionX.Custom.OptimizersOptimizerPreview
Optimization fitnessHyperionX.Custom.OptimizationFitnessesOptimizationFitnessPreview
Money managementHyperionX.Custom.MoneyManagementsMoneyManagementPreview
CommissionHyperionX.Custom.CommissionsCommissionPreview

Use the exact installed templates and Extension Type Catalog before choosing a namespace or base. Do not infer a contract from a class found elsewhere in the desktop source.

Lifecycle And Data

The normal indicator/strategy contract is built around:

  • OnStateChanged() for defaults and runtime configuration;
  • OnBarUpdate() for bar-driven logic;
  • supported update hooks documented in Lifecycle Reference;
  • Open, High, Low, Close, Volume, DateTime, and Input series;
  • CurrentBar and the documented multi-series collections;
  • Series<double>, Plot, AddSeries(...), and supported plot registration;
  • public drawing, rendering, and managed strategy-order helpers.

Use Code Lab API Reference for a quick member map and the dedicated reference pages for signatures and lifecycle detail.

Parameters And Generated Helpers

Editable script settings use [HyperionXProperty] together with supported .NET metadata such as [Display], range validation, and XML/serialization attributes where documented.

Indicator convenience helpers are generated from compilable public indicator classes and supported parameters. A green editor build is not the final runtime test: runtime activation performs a separate authoritative compile/load pass. See Parameters And Generated Helpers and Build, Test, And Debug.

Orders

Strategies should use the documented managed entry, exit, stop, and target helpers for normal workflows. Direct SubmitOrder(...) use transfers working-order tracking, partial-fill handling, cancel/replace behavior, and OCO coordination to the extension.

No script API removes the need to verify the selected account and provider state. Test with LocalPaper. Playback does not select it automatically; do not rely on a build-specific external-account guard to correct the selection.

Preview SDK Runtime Adapter

The reviewed 1.1.12-versioned source snapshot contains runtime hosts and source generation that adapt HyperionX.SDK indicator and strategy bases into the desktop calculation engine. This changes the earlier reference-only state, but it does not make the adapter a stable public API or prove its presence in the distributed MSI.

Until a release promotes it:

  • use the generated HyperionX.Custom model for release-compatible customer extensions;
  • do not advertise a direct SDK-based extension as compatible with the stable 1.1.12 public contract;
  • do not depend on adapter-generated class names or internal host implementation details;
  • retest discovery, parameters, lifecycle, plots, orders, unload, and rebuild behavior against the signed target package.

Local Desktop API Preview

The local HTTP interface binds to 127.0.0.1, tries ports 5217 through 5226, and requires the desktop token for requests other than CORS preflight. It exposes capability discovery and scoped chart, news, drawing, Code Lab, research, chat, and trading-action routes. An enabled installed build can expose guarded Hyperion Sim, Hyperliquid, and KuCoin actions only when the corresponding release capability and provider-specific gates are present.

The contract is capability-driven: a client must inspect the installed build instead of assuming a route or entitlement. Current limitations include:

  • no supported public UI for copying or rotating an app-generated token;
  • no public OpenAPI document or generated client;
  • no chart identifier for multi-chart targeting;
  • no streaming route;
  • Hyperliquid and KuCoin live support is release-gated and capability-discovered rather than implied by the route or entitlement alone;
  • no stable compatibility guarantee beyond the installed capability response.

Agent Builder profile settings do not scope the global HTTP token. A request confirmation field is supplied by the caller and does not create an independent desktop approval dialog.

Use Local Desktop API for shared routes, authentication, permissions, and audit records. Use Local Agent Live Trading API only when the installed build explicitly enables the release-gated live workflow.

Internal Boundaries

Public extensions and integrations must not depend on:

  • WPF windows, controls, view models, or dispatch implementation beyond the documented add-on context;
  • concrete provider adapters, credentials, sessions, or native SDK wrappers;
  • desktop controllers, build services, licensing services, repositories, database entities, or file formats;
  • managed Rion bridge transport or cloud command envelopes;
  • Marketplace endpoints, authorization flows, package proofs, follower messages, or storage formats;
  • undocumented members exposed through a broad object such as an internal session reference.

An internal type being public in a .NET assembly is not a promise of compatibility.

Compatibility Rules

  1. Record the exact HyperionX version used to build and test an extension.
  2. Compile and activate it in a clean installed environment, not only a source checkout.
  3. Use only members documented as Current or an explicitly accepted Preview dependency.
  4. Treat a platform upgrade as a compatibility event; rebuild and rerun lifecycle, data, and order tests.
  5. Keep class names unique across the shared custom project.
  6. Package source only through the documented reviewable source workflow.
  7. Do not bundle credentials, customer data, compiled platform assemblies, or internal endpoints.
  8. Document provider, entitlement, and Preview dependencies for users.

Where To Continue