Perception
- IN
- A consented live or recorded interaction
- OUT
- Measured signals and explicit availability state
Signal, never an emotion label
Developer documentation
Build at the boundary between signal, memory, and conversation.
This is the canonical home for ONIOKO integration documentation. SDK packages, API resources, realtime delivery, authentication, errors, retention, and deletion are documented here—not inside the pages that explain the models.
Developer access is currently controlled. We do not publish placeholder package names, endpoint paths, schemas, or version numbers. Exact references appear here when their contracts are stable.
- Access
- Controlled
- Public SDK packages
- Not released
- Public endpoint reference
- Not released
- Integration documentation
- Provided during onboarding
01 / Overview
Choose the boundary you integrate with
ONIOKO is not one undifferentiated API. Each boundary has a different data lifetime, consent requirement, and failure mode. An integration begins by choosing the narrowest boundary it needs.
Session context
- IN
- The current conversation and supplied material
- OUT
- Short-lived context for the active interaction
Expires; it is not long-term memory
Memory
- IN
- Provenance-bearing statements and observations
- OUT
- Person-bound continuity across sessions
No cross-person memory
Presence
- IN
- A product channel such as chat, voice, or video
- OUT
- A conversational interface to the selected capabilities
The channel does not erase the underlying boundaries
02 / Integration contract
The integration contract comes before the code
Every client and endpoint must preserve five things. A convenient wrapper is not allowed to hide them.
- 01
Consent
Establish the permitted channels and purpose before capture or processing.
- 02
Identity
Bind context and memory to the intended person and tenant.
- 03
Availability
Carry measured and unavailable states explicitly; never turn absence into zero.
- 04
Provenance
Keep the source and status of statements, observations, and interpretations.
- 05
Lifecycle
Make retention, export, and deletion behavior visible to the integrator.
03 / SDKs
SDKs are versioned clients, not a marketing label
A public ONIOKO SDK will only be listed when it includes installation instructions, typed interfaces, authentication guidance, runnable examples, semantic versioning, migration notes, and a changelog. Until then, integrations use the controlled documentation supplied during onboarding.
Browser and realtime
Controlled accessCapture and live-session integration with explicit consent and availability handling.
Server
Controlled accessTenant-safe requests, orchestration, exports, and deletion from trusted infrastructure.
Events
Controlled accessTyped handling for asynchronous results, retries, ordering, and idempotency.
04 / APIs
APIs are documented by resource and lifecycle
The public reference will define exact authentication, request and response fields, errors, pagination, rate limits, idempotency, and version policy. This page does not invent endpoint paths before that reference exists.
Sessions
Create and close bounded interaction contexts; inspect their processing status.
Perception
Submit or stream consented inputs; receive measured signals or an unavailable state.
Memory
Write and retrieve person-bound records with source and provenance intact.
Subjects and consent
Manage the identity and permissions that constrain every other resource.
Export and deletion
Request portable data and verifiable lifecycle operations.
05 / Events
Realtime and asynchronous delivery need their own rules
Live updates and background results are separate from request-response APIs. Their documentation must explain when an event is emitted, whether it can repeat, and how clients recover.
- Ordering
- State whether order is guaranteed and within which scope.
- Retries
- Document retry windows and duplicate delivery.
- Idempotency
- Give consumers a stable way to process an event once.
- Unavailable
- Emit absence as a status, not as fabricated measurements.
- Verification
- Document how a receiver verifies the sender before accepting data.
06 / Trust
Trust is part of the interface
Security, consent, provenance, and deletion are not separate policy pages that an SDK can ignore. They shape the client defaults and every API contract.
- Credentials
- Secret credentials belong on trusted servers, never in browser code.
- Tenant isolation
- A request must stay inside the institution and person it was authorized for.
- Data minimization
- Integrate only the channels and retention the use case needs.
- Observability
- Log status and provenance without logging secrets or unnecessary raw inputs.
- Deletion
- Expose who can request deletion, what it covers, and when completion is confirmed.
Release gate
What must exist before a public release
The public surface is considered released only when all of these are published together.
- Package or base URL
- Authentication guide
- Complete typed reference
- Runnable quickstart
- Errors and recovery
- Rate limits and quotas
- Versioning and deprecation policy
- Changelog and migration guide
- Consent and data-lifecycle guide
- Support and security contact
Need the current integration documentation?
Tell us which product, channel, and data boundary you need. We will provide the controlled reference that matches that integration instead of handing you a fictional public API.