Admin Portal production

A credential is an API key tied to one tenant. Partners send it as X-Api-Key on api-test.idunox.com. See Glossary → Credential.

Staff admins who can sign in to this portal. You cannot delete/deactivate your own account or the last active admin. Tenant & submission deletions require a second admin to approve — keep at least two active.

A submission is one lab result ingest request from a partner — scoped to the tenant derived from their API key, not from body fields alone. See Glossary → Submission. Rows with status REJECTED are POSTs rejected at intake (4xx) — sourced from the platform audit log, retained 90 days, with the error code in the Error column (hover for field-level reasons). 401/429 requests are not listed (see the partner-submission-failure runbook).

Submission activity over the selected window — platform totals and per-tenant breakdown. See Glossary → Stats.

Every staff change in this portal, and every key change a partner makes in the partner portal, newest first: who did it, when, to what, and the reason given. The list is read-only. Each row was written in the same database transaction as the change it records. Partner submission rejections are on the Submissions tab.

Definitions for terms used across this staff portal and the andres-test partner API.

• Tenant
  One customer or lab organization in the platform. Every API key, submission, result, and report artifact belongs to exactly one tenant. Tenants are the isolation boundary — partners never share data across tenants.
  
  For partner-facing demos and docs verification, prefer one multi-pack customer tenant over many throwaway tenants. Do not merge tenants by editing JSON alone: credentials, subjects, submissions, jobs, results, artifacts, webhooks, idempotency keys, and audit logs are tenant-scoped records.
• Credential (API key)
  A secret issued to a tenant for machine-to-machine access. Stored as a hash + prefix only; the full secret is shown once at creation. Sent on each request as header X-Api-Key. Inherits the tenant’s pack entitlements.
• Internal key
  An API key that Idunox uses inside a customer tenant, for deploy probes, release gates and audits. Mark it on Credentials with an audit reason. The partner portal then hides the key and every submission, result, rejection and count made with it. Nothing is deleted, and the partner cannot revoke or rotate the key. A rotated internal key stays internal. An internal key is never deleted, because its traffic would show to the partner again: revoke it instead. Stats can include, exclude or isolate internal traffic.
• Submission
  A single POST /v2/submissions ingest (the only partner contract; /v1 was removed on 2026-10-09) — partner blood markers and metadata entering the pipeline. The tenant is determined from the API key, not from partner IDs in the JSON body.
• Slug
  A short, URL-safe identifier for a tenant (lowercase letters, numbers, hyphens). Used in key labels, scripts, and ops — e.g. health-yourself for Health Yourself.
• Pack
  A licensed Idunox product — Health Yourself, Pilot, or Care. A pack defines the marker intake scope (questionnaire + blood analytes), wellbeing outcomes, model bundle, report layout, and which partner documentation slices a tenant may view.
  
  What you assign to a tenant: a pack (product license), stored in tenant.metadata.assignedPackIds. The platform may dual-write derived input panel IDs beside them, but Staff UI and /v2 entitlement always use pack IDs (Care must not collapse to Pilot in the picker).
  
  Where used: pack guard on POST /v2/submissions (403 PACK_NOT_ASSIGNED when the requested pack is not assigned); partner docs entitlement by pack ID; report template and model routing from the accepted pack snapshot. Customer tenants usually have one pack; lab tenants are for internal parity only.
• Panel ID
  Stable machine identifier for a pack's input marker vocabulary, e.g. iduscore_health_yourself, iduscore_pilot. Care currently shares Pilot's input panel while remaining a distinct licensed pack ID (iduscore_care).
  
  Where used: derived operational metadata dual-written beside assignedPackIds; never accepted as a public /v2 selector. Partners POST the /v2 wire with required packId plus Q/B guide ids — not panelId.
• Partner API version
  The partner API is a single documented contract — /v2; the URL path is the contract and no format headers are used. All andres-test partners integrate on /v2, and the Partner Portal API reference exposes pack selection only (there is no API-version selector). The legacy /v1 partner API and its format headers were removed from the runtime on 2026-10-09; every /v1 partner path answers 404. The portal routes under /v1/partner and /v1/admin are separate and unchanged. Staff do not choose a tenant-level “Partner API contract” dropdown.
• Report JSON version
  Downloadable JSON report schema. On /v2 it is the normalized partner_report_json_v2, fixed server-side by packId (both HY packs emit it); staff do not choose it in Admin, and /v2 uses no format header. (HY results stored before the J-R26 core deploy also carry a partner_report_json_v1 artifact; new HY results store only v2. No partner route has served v1 since /v1 was removed on 2026-10-09.) The deployed v2 artifact is normalized: areas stay in wellbeingAreas[], all Q/B/D markers and marker-to-area ranks live in markers[].areaContributions[], and action ranks live in actions[].priority plus actions[].supportedAreas[].rankInArea.
• Panel (marker profile)
  The full marker and model profile behind a pack: required blood marker guide ids (B### on partner wire), questionnaire Q001–Q037, inference model bundle, and report template. Docs often say “14-marker panel” or “13-marker panel” for the blood analyte list only — that list is part of the panel profile, not the whole product. Do not confuse with UI “tabs” in this portal (those are navigation panels).
  
  Where used: validation presets (panel-blood-marker-presets.js), pack guard inference, parity fixtures, and pack-specific input-data guides. One pack ↔ one panel profile today; panel ID is the join key.
• Type (Customer vs Lab)
  Customer — real partner-style tenant (e.g. Health Yourself). Lab — internal andres-test tenant for gates and pack parity; not for production partner traffic.
• Prefix
  The first characters of an API key stored for support and UI display (e.g. idu_prod_sk_… for production keys, idu_dev_sk_… for dev). Lets staff identify a key without revealing the full secret.
• Status (credential)
  Active — key accepts API calls. Revoked — key rejected immediately; use when rotating or deprovisioning access.
• Partner submission ID
  The partner’s own identifier for a submission (their idempotency / trace id). Distinct from our internal submission UUID.
• Audit reason
  Required note on create, update, revoke, and pack changes — who did what and why. Stored in row metadata today (lastAdminChangeReason); a separate audit_logs table (model AuditLog) also exists, populated by the platform pipeline.
• API base URL
  Partner integration endpoint for andres-test: https://api-test.idunox.com (version-neutral host; the current contract is /v2, e.g. /v2/submissions). Docs live in the partner portal at partner-test.idunox.com/docs.
• Stats
  Dashboard cards: platform totals (submissions, completion rate, active keys) plus per-tenant breakdown over the selected day window. The Internal keys menu decides whether traffic from internal keys counts; the heading names the choice.
• Staff sign-in
  Email invitation → set password → sign in with email, password, and a mandatory one-time code sent by email on every login. Production URL: admin-test.idunox.com. Local dev: bash scripts/deploy/phase19_admin_ui_local_dev.sh → port 8791.

Staff guide for the andres-test Admin Portal. For term definitions see Glossary.