Device platform · design stage

One contract for
personal hardware.

Every wearable exposes a different surface, a different auth model and a different idea of what a screen is. Glance turns that into data: each class of device declares what it can do, and a fixed vocabulary of interactions resolves against the declaration.

even-g2 1/2

Personal hardware speaks nine
different dialects. Glance is
the contract that lets one
system talk to all of them —
without caring which watch,
ring or lens is listening.

A device declares what it can
do. The vocabulary resolves
against that declaration.

Support is derived, never
hand-maintained.

6 × 32

This card is six lines of thirty-two characters, which is the geometry the reference device declares. The copy does not fit, so it renders in two frames instead of erroring. That rule — degrade, don’t fail — is written into the contract, and this is it running.

Design stage The contract is ratified and published below. Nothing is deployed to hardware yet, and no device integration is running in production.

The finding that decides everything

One field separates hardware you can build on from hardware you can only admire.

Every device in the assessment falls on one side of a single line: can server-side code reach it, or does reaching it require a native mobile app? This is not a detail of the integration. It decides whether there is an integration.

reachable_from: server

The device is reachable from ordinary server-side code. No mobile app, no app store, no second codebase to maintain. An integration is a service next to everything else you already run.

10 of 21 assessed devices

reachable_from: phone-app-only

Reaching the device means building and shipping a native iOS or Android app first. Best-in-class hardware lands here, and it stays out of reach until someone writes and maintains that app.

11 of 21 assessed devices

The consequence is uncomfortable and worth stating plainly: the best display hardware currently on sale is on the wrong side of this line, and no amount of specification changes that.

The contract · profile schema v1

A profile is data. Adding a device means writing one.

A profile declares what a class of device can do and how to reach it — transport, auth, capabilities, budgets, delivery. It is not code, and it is not a driver. Adding a device means writing a profile, and only writing an adapter if the transport is genuinely new.

even-g2.yaml

transport:
  kind: cloud-sdk
  reachable_from: server

auth:
  kind: pat
  refresh: none
  entitlement: ""

capabilities:
  display:
    lines: 6
    chars_per_line: 32
    images: false
  input:
    events: [tap, swipe]
  audio:
    in:  { raw: true, rate: 16000 }
    out: null
  camera: null
  sensors: []

budgets:
  battery_class: hours
  offline: cache-required

delivery:
  push: true

Three fields carry most of the weight

transport.reachable_from: Server, or phone-app-only. One field encodes the whole architectural constraint, and it is why the exclusion above needs no special case anywhere in the code.
auth.refresh & auth.entitlement: Some vendors return a new refresh token on every refresh, so token state must survive a restart. Others gate API access behind a subscription, so a lapsed membership presents as a broken job rather than an auth error. Both are facts about the device, not trivia about the implementation.
budgets.battery_class: What the platform’s own load costs, never the vendor’s claim. A headline two-day figure that means hours under display, radio and microphone together belongs in the profile as hours.

The vocabulary

Eight interactions. You write against these, never against a device.

Each one names a capability it requires. A device supports an interaction if and only if its profile satisfies that requirement — so support is derived, never maintained by hand. Write a profile for a new gadget and everything it can do works the same day.

card.push to device

Put a short piece of content in front of the wearer.

requires a display
card.ack from device

The wearer acknowledges. This is what makes seen different from sent.

requires any input event
choice.prompt round trip

Ask a question with a small number of answers, and get one back.

requires a display and any input event
lesson.deliver to device

A sequenced, resumable series of cards. Advance, pause, pick up where it stopped.

requires a display and at least one input event
capture.start / stop from device

Record what the wearer says, bounded by an explicit start and stop.

requires audio input
speak to device

Say something out loud, in the wearer’s ear.

requires audio output
reading.sync from device

Pull the day’s measurements on a schedule.

requires at least one sensor reading type
frame.request round trip

Capture what the wearer is looking at, on an explicit trigger.

requires a camera

Capability resolution

Support is computed, not declared.

Every cell below is the output of the resolution rules run against the profiles in this page’s own source. Nothing here was typed in by hand. Change a profile and the table changes with it — which is the claim being made, so it had better be true of the page making it.

Card height

● supported ◐ degraded but delivered ○ unsupported

Which interactions each device profile supports, for a card of 6 lines
Interaction	Even Realities G2 Server-reachable display terminal	Meta Ray-Ban Display Phone-app-only	Oura Ring Pure-sensor vendor API	Whoop Strap Pure-sensor vendor API
`card.push`	supported	not server-reachable	no display	no display
`card.ack`	supported	not server-reachable	no input events	no input events
`choice.prompt`	supported	not server-reachable	no display	no display
`lesson.deliver`	supported	not server-reachable	no display	no display
`capture.start / stop`	supported	not server-reachable	no audio input	no audio input
`speak`	no audio output	not server-reachable	no audio output	no audio output
`reading.sync`	no sensor readings	not server-reachable	supported	supported
`frame.request`	no camera	not server-reachable	no camera	no camera

Which interactions each device profile supports, for a card of 8 lines
Interaction	Even Realities G2 Server-reachable display terminal	Meta Ray-Ban Display Phone-app-only	Oura Ring Pure-sensor vendor API	Whoop Strap Pure-sensor vendor API
`card.push`	D1 paginate	not server-reachable	no display	no display
`card.ack`	supported	not server-reachable	no input events	no input events
`choice.prompt`	D1 paginate	not server-reachable	no display	no display
`lesson.deliver`	D1 paginate	not server-reachable	no display	no display
`capture.start / stop`	supported	not server-reachable	no audio input	no audio input
`speak`	no audio output	not server-reachable	no audio output	no audio output
`reading.sync`	no sensor readings	not server-reachable	supported	supported
`frame.request`	no camera	not server-reachable	no camera	no camera

Switch the card height. At six lines everything the reference device can show, it shows. At eight it no longer fits — and rather than failing, three interactions drop to degraded and paginate. Nothing in the table was edited to make that happen.

Read the second column. It is uniformly unsupported, and no rule anywhere names that vendor. One declared field did all of it. That is the test of whether an abstraction is doing real work: the awkward case falls out of the rules instead of being special-cased around them.

Degraded is a result, not a failure. Six lines of content on a four-line display renders in two frames. A device with no server-to-device push gets the same card pre-pushed into its cache on its own poll cycle. The interaction still happens; the profile decides how.

The landscape · assessed 13 August 2026

24 devices, sorted by whether you can actually build on them.

Vendor developer documentation read directly, one question asked of each: can server-side code reach this without a native mobile app in the chain? Not a review. Nothing here says whether the hardware is any good — only whether it is reachable, and what will bite you if it is.

Display glasses

Does well The only category that puts text in your eyeline without occupying a hand.

Does badly Nothing runs on the glasses. On every available platform they are a display-and-sensor terminal, and the code lives somewhere else.

Product image © Even Realities

Even Realities Even Realities G2
Server-reachable

MentraOS cloud SDK — display, microphone, touch gestures, battery, brightness

MentraOS apps run in the cloud with a low-latency link to the hardware. That means the app is an ordinary server-side service, with no mobile development and no app store.

The catch The two-day battery figure is a notification duty cycle, not a load figure. Reviewers report around five hours on a heavy day, and nobody has published a test of display, Bluetooth and microphone running concurrently — which is exactly the load an always-on integration imposes.

A$1,199 MentraOS audio chunks
Product image © Vuzix

Vuzix Z100
Server-reachable

Supported by MentraOS alongside the Even Realities line

Inherits the MentraOS architecture, so the same server-side path applies.

The catch Australian pricing and availability not established in this pass.
Product image © Meta

Meta Ray-Ban Display
Phone app only

Wearables Device Access Toolkit — text, images, lists, buttons, video

The toolkit opened to third parties in May 2026, and it is explicitly not an operating system for glasses. It lets a native mobile app reach into the display and sensors, so reaching the device from a server means building and maintaining an iOS or Android app first.

The catch Still a developer preview — general distribution through the App Store or Play was not yet possible as of May 2026. So the path requires an app that cannot be shipped, to reach a device only that app can talk to.

Meta wearables developer FAQ

Recovery, sleep and readiness

Does well Passive to the point of invisibility — no interaction cost at all, which is the opposite of every other category here. Multi-day to multi-week battery.

Does badly The scores are proprietary composites. A ring is a pure sensor: no display, no input, nothing to write to. On the market leader the data is behind a subscription.

Product image © Oura

Oura Ring
Server-reachable

v2 REST plus webhooks. OAuth2 or a Personal Access Token. 50+ metrics including raw heart rate and inter-beat intervals

Best in class for reachability. A Personal Access Token is a single-user credential, so there is no OAuth dance at all — one HTTP node is enough to pull the whole dataset on a schedule.

The catch API access is membership-gated, and this is the expensive detail. Lose the subscription and you lose the API — the hardware keeps working, the integration does not. It presents as a broken nightly job rather than an auth error, so it gets debugged as an integration fault.

A$649–799 plus A$9.99/mo or A$109.99/yr The Oura API
Product image © Whoop

Whoop Strap
Server-reachable

REST, OAuth2 authorization-code only. Scopes read:cycles and read:recovery. 100 requests/min, 10,000/day

Server-reachable, with the caveat that the auth is the expensive part — there is no Personal Access Token equivalent.

The catch Every refresh returns a NEW refresh token. Token state has to be persisted to durable storage and survive a process restart. Holding it in config works right up until the first restart, after which the integration is dead and cannot re-auth without a human repeating the OAuth flow.

WHOOP rate limiting
Product image © Samsung

Samsung Galaxy Ring
Phone app only

Health Data SDK

Galaxy Ring APIs are not exposed to third parties, and the SDK is on-device Android.

Samsung Health Data SDK
Garmin Health API
Closed to new access

All-day metrics, sleep stages, stress, HRV

Business use only, through the Partner Program, and the Connect Developer Program is not accepting new applications.

The catch Connect IQ is a separate and genuinely open program — see the wrist category. Two different Garmin programs, and only one of them is open. Confusing them costs an afternoon.

Connect Developer Program FAQ
Product image © Ultrahuman

Ultrahuman Ring Pro
Not assessed

Not established

In the field and read for positioning only. The API surface was not assessed, because the category verdict did not turn on it.
Product image © RingConn

RingConn Gen 2
Not assessed

Not established

In the field and read for positioning only. The API surface was not assessed.
Product image © Circular

Circular Ring 2
Not assessed

Not established

In the field and read for positioning only. The API surface was not assessed.

Voice capture and recorders

Does well Room capture — the one thing glasses cannot do, because their microphone arrays are built to isolate the wearer and suppress everyone else.

Does badly Social and legal friction is the whole problem. A device that records the other side of a conversation needs consent in a way a notification display never does.

Limitless Pendant
Server-reachable

Seven REST endpoints including raw audio download as Ogg Opus, up to two hours per request. Plain X-API-Key header. 180 requests/min. Hosted MCP server

The strongest documented read path in the entire assessment. Key auth plus REST plus raw audio download means a scheduled job can hold the whole corpus with no mobile app anywhere in the chain.

Limitless Developer Platform
Product image © Omi

Omi Dev Kit 2
Server-reachable

Open source, open hardware, local processing

The only sovereignty option in the category. Explicitly built to bypass the proprietary cloud and run processing locally, which makes it the one device where you can hold the audio end to end.

~US$89 Omi
Product image © Plaud

Plaud Note / NotePin
No public API

Vendor MCP and CLI. Manual export as TXT, SRT, JSON

Best device in the category, weakest personal programmability. There is no public personal API — the Developer Platform is a business motion for putting Plaud capture inside someone else’s product.

The catch The MCP and CLI need no API key and no waitlist, but there is also no documented contract to build against. Fine for a person, not something to found a pipeline on.

Plaud API access
Product image © Bee / Amazon

Amazon Bee
No public API

No personal API surfaced

Acquired by Amazon in July 2025 and shown at CES 2026 on the Alexa roadmap. Cheapest way into the category, and the most captured by a platform.

US$49.99 Why Amazon bought Bee

Audio wearables, no display

Does well Audio in and out at essentially zero social cost. Live translation and speech enhancement shipped here first.

Does badly Every answer must be spoken. Audio is a poor channel for lists, numbers, and anything you want to re-read.

Product image © Shokz

Shokz and similar Open-ear earbuds
Server-reachable

None. A Bluetooth audio sink

The un-glamorous finding, and the most immediately useful one. Ordinary open-ear earbuds have no API at all, which makes them the one output channel reachable today: server-side text-to-speech, the phone as a Bluetooth relay, and any audio device renders it. Zero integration, zero new platform.

The catch It is not an eyes-up interface and it never will be. It is worth knowing that it costs nothing to test whether the idea is any good before buying the form factor.
Product image © Meta

Meta Ray-Ban Meta Gen 2
Phone app only

Device Access Toolkit covers camera and audio via the mobile SDKs

Same architecture as the Display model — the SDK path needs a native app that cannot yet be shipped.

The catch Two-way voice runs over HFP at 8 kHz mono, telephone quality. The microphone array beamforms toward the wearer and significantly reduces ambient sound and other speakers. Correct for dictation, wrong for minuting a meeting.

Conversation Focus
Product image © Apple

Apple AirPods
No public API

Live Translation, in-ear, with a transcript in the app

No third-party API. Apple is reported to be building an accessory-pairing API that would cover third-party hardware, but pairing is not data.

AirPods Live Translation

Neural and gesture input

Does well Solves input, which the display category barely addresses. Silent, invisible, hands-down-at-your-side control.

Does badly No standalone hardware and no standalone SDK. Events reach a phone, not a server.

Product image © Meta

Meta Neural Band
Phone app only

sEMG wristband. Scroll and click today, text entry stated as near-term

Reads forearm muscle signals and turns micro-movements into discrete input events — silent, invisible, hands-at-your-side input. It solves the half of the problem the display category barely touches.

The catch Bundled to Meta’s stack. No standalone band, no standalone SDK, no way to use it as a generic input device for someone else’s app. It inherits the same architecture problem: events reach a phone, not a server.

Meta EMG wearable technology

On-wrist app platforms

Does well Inverts the finding above: a Connect IQ app in Monkey C genuinely runs on the device, fetches JSON from any web service, and writes to the display.

Does badly No documented server-to-device push for custom apps — the app polls, so refresh cadence trades directly against battery.

Garmin Connect IQ
Server-reachable

Monkey C apps that run on the device. Toybox.Communications.makeWebRequest fetches JSON from any web service; Toybox.Notifications writes to the display

The one platform where third-party code genuinely runs on the hardware. A widget covers six lines of text, a button to advance, and a pre-pushed cache — on hardware in the A$300–700 band, or hardware you already own.

The catch No documented server-to-device push for custom apps, so the app polls and refresh cadence trades against battery. Monkey C is a niche language with niche tooling, and distribution runs through the store even for personal use.

Toybox.Communications
Product image © Apple

Apple Apple Watch
Phone app only

watchOS apps, paired to an iOS app

Code runs on the device, but the distribution and data path runs through a paired iOS app and the App Store.
Product image © Google

Google Wear OS
Phone app only

Android apps on the watch

Same shape as watchOS — real on-device code, reached through a mobile app rather than a server.

The aggregation layer

Does well One integration instead of many, if you have enough users to amortise it.

Does badly Priced for products with a user base. At one person it is thousands a year to avoid writing two OAuth flows.

Product image © Terra

Terra Terra
Server-reachable

One API across many vendor wearables

Genuinely solves the many-vendors problem, and is priced for a product with a user base.

The catch US$399/mo on an annual plan for 100,000 credits, at roughly 200 credits per active user per month. For one person that is around US$4,800/yr to avoid writing two OAuth flows. Direct per-vendor integration wins outright at small scale.

US$399/mo annual, US$499 monthly Terra
Various Rook, Vital, Metriport
Server-reachable

Same shape as Terra

Same trade and same arithmetic. They become interesting when a product needs many users’ data, at which point it is a build-versus-buy decision with real numbers attached.
Apple, Google HealthKit / Health Connect
Phone app only

On-device stores

Reaching either requires a mobile app, which is the same wall as everything else in this survey.

What this assessment deliberately did not cover

A landscape with unmarked edges reads as complete when it is not. These are the edges.

Enterprise and industrial wearables: Genuinely adjacent for the factory-floor case, and the clearest edge of this pass. The obvious start point for the next one.
Hearing-aid-class and medical wearables: ECG patches, sleep apnoea, blood-pressure cuffs. A clinical category with a different regulatory frame.
VR and MR headsets: Not a wearable in the all-day sense.
Hands-on review depth: Reviews were read for availability and battery behaviour, not to build a purchase shortlist.
Consent law for always-on recording: A real constraint on the capture category, and not a technology question. It should be answered before a recorder is used in a meeting, not before one is bought.

Server-reachable Reachable from server-side code. No mobile app anywhere in the chain.

Phone app only Requires a native iOS or Android app to reach the device at all.

Closed to new access A documented API exists, and it is not open to new applicants.

No public API No public programmatic surface for personal use.

Not assessed In the field, deliberately not assessed in this pass.

Working with us

Most hardware integrations fail on the boring question.

Not what the device can do — whether your systems can reach it at all, what happens when the battery figure is marketing, and which vendor gate turns into a silent outage six months in. That is the work this page is a byproduct of.

Talk to us about an integration More from TrendAI

Assessment last reviewed 20 August 2026. Profile schema v1. Corrections are welcome — if a verdict here is out of date, we would rather know.

One contract for personal hardware.