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:
| Method | Header | Use |
|---|---|---|
| Session bearer | Authorization: Bearer <token> | Apps acting on behalf of a signed-in StackOS account. |
| User id | x-helix-user-id: <id> | Server-to-server / local development against your own account. |
Platform API
A RESTful surface over the same engine the builder uses. Base URL https://app.neurastack.com/api/helix.
| Method | Endpoint | Does |
|---|---|---|
| POST | /app-builder/compile | Generate an app from a prompt (also /compile/stream for SSE progress). |
| POST | /apps/:id/install | Install a generated app for the owner. |
| POST | /apps/:id/action | Run an app action; returns new runtimeState + rendered surface. |
| POST | /apps/:id/runtime | Patch the app's runtime state directly. |
| GET | /apps/:id/events | Run history (actions, automations, webhooks, failures). |
| DEL | /apps/:id | Uninstall / 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>
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.
| Piece | What it is |
|---|---|
HelixService | On-device WebSocket bridge to the server (state sync, actions, media, telemetry). |
App Activity | Your screen + scroll-wheel/select/back input handling, bound to the service. |
| App drawer | Discovers launchable activities; your app appears once registered in the manifest. |
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:
| Capability | Status |
|---|---|
| Generate / install / run apps over HTTP | Live |
| Inbound + outbound webhooks, MCP connections | Live |
| App runtime SDK (StackOS / StackOSNav) | Live |
| Native glasses apps via HelixService | Live (source-level) |
| Scoped developer API keys | Planned |
| Public WebSocket client + Bluetooth/BLE SDK | Planned |
| Native plugin SDK (no OS fork) | Planned |