StackOS for Developers

Build on smart glasses.
Beyond the prompt.

Most people build StackOS apps by describing them in a sentence. When you need more — to drive the platform programmatically, wire your own services, ship custom runtime UIs, or write native glasses code — this is your surface.

Platform API

Generate, install, and run apps over HTTP. Drive any app's actions from your own backend.

🧩

Runtime SDK

The StackOS JS API your app's glasses + phone surfaces call to act and navigate.

🔌

Webhooks & MCP

Receive events into an app, post events out (HMAC-signed), and attach remote MCP tool servers.

📱

Native glasses apps

Write Kotlin activities against the on-device Helix bridge for fully custom hardware apps.

Quickstart

Generate an app from a prompt and trigger one of its actions — entirely over HTTP.

1 · Generate an app

# POST a prompt to the builder. Returns a full app package.
curl -X POST https://app.neurastack.com/api/helix/app-builder/compile \
  -H "x-helix-user-id: $YOUR_USER_ID" \
  -H "Content-Type: application/json" \
  -d '{ "prompt": "a hands-free workout logger that suggests my next set" }'

2 · Install it

curl -X POST https://app.neurastack.com/api/helix/apps/$APP_ID/install \
  -H "x-helix-user-id: $YOUR_USER_ID"

3 · Drive an action

curl -X POST https://app.neurastack.com/api/helix/apps/$APP_ID/action \
  -H "x-helix-user-id: $YOUR_USER_ID" \
  -H "Content-Type: application/json" \
  -d '{ "actionType": "logSet", "payload": { "reps": 10, "weight": 135 } }'

# → { runtimeState, glasses, manifest } — the app's new state + rendered surface.

Authentication

Every /api/helix/* call is owner-scoped. Today there are two ways to authenticate:

MethodHeaderUse
Session bearerAuthorization: Bearer <token>Apps acting on behalf of a signed-in StackOS account.
User idx-helix-user-id: <id>Server-to-server / local development against your own account.
Roadmap: scoped, revocable developer API keys (instead of the user-id header) are the next addition for production third-party integrations. Until then, keep the user-id header server-side only.

Platform API

A RESTful surface over the same engine the builder uses. Base URL https://app.neurastack.com/api/helix.

MethodEndpointDoes
POST/app-builder/compileGenerate an app from a prompt (also /compile/stream for SSE progress).
POST/apps/:id/installInstall a generated app for the owner.
POST/apps/:id/actionRun an app action; returns new runtimeState + rendered surface.
POST/apps/:id/runtimePatch the app's runtime state directly.
GET/apps/:id/eventsRun history (actions, automations, webhooks, failures).
DEL/apps/:idUninstall / delete an app.

Plus sessions (Eliza chat), provider routing, voice/TTS, and device registration — all under the same base and auth.

Generate & install

Compile is synchronous by default and can take up to a few minutes (the build runs a real end-to-end journey proof). For UIs, stream progress with /compile/stream (Server-Sent Events).

Drive app actions

The action endpoint is the core integration primitive: it runs the app's authored logic for actionType with your payload and returns the resulting state and a rendered glasses/phone surface — so an external system can operate a StackOS app headlessly.

App runtime SDK

Every StackOS app surface (the 640×400 glasses HUD and the phone companion) runs inside a thin, additive runtime that wires tagged elements and leaves everything else you author alone. You write arbitrary HTML/CSS/JS; the runtime gives you a small API to act, navigate, and re-render.

JS API & declarative bindings

// Imperative — call from your own inline script
StackOS.runAction("logSet", { reps: 10 });  // run an action; new state arrives via re-render
StackOS.getState();                         // read current runtime state
StackOS.onStateUpdate(render);              // re-run your render on every state push
StackOSNav.go("detail", { id: 7 });        // push a screen (data via StackOSNav.data())
StackOSNav.back();                          // pop the nav stack
<!-- Declarative — the runtime wires these for you -->
<button data-action="logSet">Log set</button>
<div data-bind="lastSet.summary"></div>          // renders a state value literally
<a data-nav="history">History</a>             // forward navigation
<span data-nav-back>Back</span>
The runtime only touches elements carrying its data-attributes (data-action, data-bind, data-nav, …). Your custom DOM — a canvas game, an SVG instrument — is never reordered or rewritten.

Webhooks & MCP

Inbound webhooks

Every installed app gets a clean, opaque capability URL. POST any JSON to it to push an event into the app:

curl -X POST https://hooks.neurastack.com/whk_… \
  -H "Content-Type: application/json" \
  -d '{ "event": "order.created", "total": 42 }'
# 202 Accepted — processed async; the app's webhook_receive logic maps it into state.

The token is the credential (constant-time verified). Rate-limited per app; large bodies bounded.

Outbound webhooks

Register your own endpoint to be notified (HMAC-SHA256 signed) when an app emits events — app.action, app.webhook_received, app.automation.ran, and more. Verify the X-StackOS-Signature header against the signing secret you get once at creation.

MCP connections

Attach a remote Model Context Protocol server to an app (Streamable HTTP). Tools are discovered automatically and become callable from the app's actions. Credentials are encrypted at rest and never travel in a shared app package.

curl -X POST https://app.neurastack.com/api/helix/apps/$APP_ID/mcp-connections \
  -H "x-helix-user-id: $YOUR_USER_ID" -H "Content-Type: application/json" \
  -d '{ "name": "My tools", "serverUrl": "https://my-mcp.example.com", "authHeader": "Bearer …" }'

Native glasses apps

For fully custom hardware experiences, write a native Kotlin app for the glasses. Native apps are Android Activity classes that bind to the on-device HelixService — the WebSocket bridge to the StackOS server — to sync state, run actions, and receive real-time pushes.

PieceWhat it is
HelixServiceOn-device WebSocket bridge to the server (state sync, actions, media, telemetry).
App ActivityYour screen + scroll-wheel/select/back input handling, bound to the service.
App drawerDiscovers launchable activities; your app appears once registered in the manifest.
Today native apps live in the glasses app source — you build against the open HelixService pattern. Roadmap: a native plugin SDK + a public Bluetooth/BLE layer so you can drive the glasses from your own mobile app without forking the OS.

Roadmap

What's live today vs. what's coming for the advanced tier:

CapabilityStatus
Generate / install / run apps over HTTPLive
Inbound + outbound webhooks, MCP connectionsLive
App runtime SDK (StackOS / StackOSNav)Live
Native glasses apps via HelixServiceLive (source-level)
Scoped developer API keysPlanned
Public WebSocket client + Bluetooth/BLE SDKPlanned
Native plugin SDK (no OS fork)Planned