Console

The neccessory console is where you manage your organization, your keys and your measurements. It is available in English and Russian, in a light and a dark theme.

The sidebar holds eight sections in two blocks, separated by a rule. The one you come back to every day: Home, Measurements, Cloud, On-device, Spend. The one you visit for a reason: Keys, Webhooks, Playground. Docs and Settings sit at the bottom, outside both. Every one of the eight has a jump shortcut — press G, then the letter printed next to it in the sidebar.

Every screen has a ⌘K search in the header. It looks up a measurement ID, a request ID, a cloud job ID, and a key by name or id — it is the fastest way in when you are debugging one specific call.

Home

What is happening with the integration right now, over a period you pick in the header: 24 hours, 7 days, 30 days or 90 days. Those four and nothing else — this screen is built on pre-aggregated counters, which are computed per preset and not for an arbitrary date range. When you need an exact window, use Measurements, which reads the records themselves and does take a custom period.

Four KPI cards: measurements, how many reached a result, average signal quality and what was spent. Only measurements carries a change against the previous period. The other three carry the number that actually explains them — how many cloud sessions were lost and how many are still in flight, the good / fair / poor split, and the balance with how long it lasts at the current pace.

Above the cards, a strip colours each of the last 90 days by its share of failures. It is always 90 days, whichever period is selected. Below the cards: measurements and failures per day (from 7 days up — the 24-hour view has no daily chart), the cloud funnel, and the latest events as they arrive.

When something is wrong, a strip appears at the top of this page and names it — cloud inference unreachable or not configured on this deployment, cloud jobs failing in the last hour (with the error codes and the key most of them came from), or a token balance running low. It is not a permanent indicator: when there is nothing to say, there is no strip.

Measurements

One feed, newest first, over everything a key does: measurements, cloud jobs and API calls in a single chronological order — there is no second tab to check and no separate call log. The buttons above the table (All, Measurements, Cloud jobs, API calls) filter that one feed by type; they do not switch between lists. Filter further by key, platform (web, ios, playground), outcome, quality, or your own userRef; paste a measurement ID or a request ID into the search box to open that record directly. Test-key rows are hidden until you ask for them.

A filter a row type cannot answer removes that type from the page rather than widening it — filtering by quality drops cloud jobs, by userRef drops API calls — so the feed never shows you rows the filter did not apply to.

Paging is by cursor: the feed loads the next page as you go, rather than numbering pages.

The period here is not limited to presets — the picker also takes any range you draw in the calendar.

Expand a row for the full metrics, the request ID, the SDK and model versions the client reported, the cloud job and what it cost, the attestation state and the raw measurement result JSON. The list exports as CSV or JSON over the current filters and period — measurements only: API call rows and test measurements stay out of the file even when the table shows them.

Cloud

Where attested results are computed and where tokens are spent, over the same four periods as Home — 24 hours, 7, 30 or 90 days. Four KPI cards (jobs, how many reached a result, seconds processed, spent), then jobs and seconds per day, a funnel showing at which stage sessions were lost — accepted, picked up for processing, result delivered — and a breakdown of the reasons the rest did not get through (frame rate below 20 fps, recording shorter than 20 seconds, no face in the frame, and the rest of the error codes).

The job table lists every cloud job: id, status, mode (stream, batch frames, batch video), the key it was billed to, seconds processed, how long it waited in the queue, how long inference took, and the tokens it was charged. Expand a row for the platform, the frames received, the measurement it produced and — where a stream fell back to a batch — the attempt it replaced or replaces. The table filters by key, mode and status, optionally includes test keys, and exports as CSV or JSON.

On-device

The tier where inference runs on the client. The top row is your organization's access: the current status, the platforms it was granted for, the dates the request was filed and decided, and the reviewer's note when there is one. Only the latest request is shown — there is no archive of past decisions on this screen.

Below it, what the tier actually buys you over the period you pick (24 hours, 7, 30 or 90 days): how many measurements were computed on the device, what the same work would have cost in the cloud, and how the signal quality compares — on-device against cloud, side by side. Then a short list of what the tier changes for you — video never leaves the device and nothing is billed, but the result is not attested, the first measurement waits for the weights to download, and the quality follows whatever front camera the client has. Last, the keys that carry on-device access, with their measurements and when each was used.

This is also where you apply for on-device access. One request can be open at a time, and a request sitting in more information needed still counts as open — you answer that one by email rather than filing another. See Obtaining keys for what the form asks.

Spend

Balance, cost and history on one screen, over 7, 30 or 90 days. Spent in the period against the previous one, the current balance and roughly how long it lasts at the current pace, the average cost per measurement, and a forecast for the month. A breakdown of what makes up the price of one measurement shows which metric sets you are paying for — they are toggled per key.

Below: spend by day, spend by key, and the ledger — every movement of the balance with its reason (welcome grant, cloud measurement charge, top-up, an admin credit or debit), times in UTC, exportable as CSV. Top up buys a token pack through Paddle; the balance is credited when Paddle reports the payment.

Automatic top-up is on the same screen: a threshold, the pack to buy and an optional monthly ceiling.

Keys

Create, view and manage your keys.

• Create a key: where it computes, an optional name, an expiry (365 days by default, or never) and the metric sets it may request.
• The secret is shown once, at creation. It is stored only as a hash, so it cannot be shown again — a lost secret is replaced by rotating the key.
• Rotate a key to issue a new secret, disable it, or delete it.

Where it computes is the key's mode, and it is chosen at creation: cloud, on_device — offered only once your organization's access request is approved — or test. Test keys carry the nk_test_ prefix, return synthetic results and are never billed; live key ids and secrets carry nk_live_. Keys issued before the prefixes existed have none and keep working exactly as before.

The metric sets (hrv, bp, spo2, emotion, gaze) decide what the key may ask for: only the enabled ones are computed and billed, and the dialog prices a measurement as you toggle them. Core metrics are always on. Checking nothing means no restriction — every metric stays available at the full price.

Per key you can also set its limits and scopes: requests per minute (empty or 0 = no limit), a monthly quota of cloud seconds, a monthly spend ceiling in dollars, the metric sets again, and — for on-device keys — the model channel (stable or beta). A test key ignores the quota and the ceiling, because nothing is billed to it; the rate limit and the metric list still apply. See Cloud → Limits & errors.

Webhooks

Manage your organization's webhook endpoints — up to five, each with a whsec_ secret shown once. The address list carries each endpoint's success rate and state; from its menu you edit the URL, rotate the secret, disable the endpoint or delete it.

Every delivery lands in a journal (time, event, HTTP response, attempts, response time), which filters down to failures alone. From there you redeliver one delivery or every failure on the page, redeliver by cloud job ID when the job never reached the journal at all, or fire a webhook.test event at your receiver.

Playground

Run a real measurement with the same engine your clients get — there is no file upload for the live modes, it is a live capture from your camera. Pick the key to attribute it to, choose on-device or cloud, and for cloud pick the delivery: stream, batch, or video — the last takes a file you upload or a clip you record on the spot. A cloud run asks you to confirm consent to processing before it starts. Watch the live heart rate and signal quality while it runs.

When it finishes you get the result rendered in place, the raw measurement result JSON exactly as your SDK or webhook would receive it, the equivalent cURL for your own backend, and the measurement saved to Measurements with the playground source.

Settings

Your profile, the interface (language, and a theme that can follow the system), password and sign-out, a summary of your on-device access, the organization's name, website and country — those last only an owner can edit — active sessions, the audit log, and deleting the organization.

Active sessions lists where you are signed in: the browser and platform, the address, when the session started and when it was last seen. You end one session, or every session but this one. Ending the current session is what sign out is for. On a deployment where the session table is not readable the section says so instead of showing an empty list.

Deleting the organization is typed-confirmation and reversible for a while. You type the organization's exact name; we immediately disable every key, abort every open cloud job with org_deleted and switch off any automatic top-up rule, then wait 30 days before erasing the data. Cancel inside that window and the keys and the rule come back — the aborted jobs do not. After it, measurements, logs, jobs, webhooks, ledger and keys are deleted for good, and any remaining token balance goes with them. While deletion is scheduled, writes to the organization are refused with org_deletion_scheduled.

Optional health parameters (age, gender, height, weight, blood type, allergies, chronic conditions) are used only for your own measurements in the Playground.

The audit log records who created, rotated or deleted a key, changed limits, created or rotated a webhook, redelivered, ended a session, or asked to delete the organization — with who did it and when.