Data onboarding
This group covers your own apps and services working with a vault directly: the onboarding routes, the Vault SDK, and integrations and external clients.
Your agents and workflows compute on data in a customer’s vault. Getting it there is onboarding, and there are several routes. Pick the ones that fit your product; your agent code does not change with the route.
The routes
| Route | Who writes | What lands | See |
|---|---|---|---|
| Already there | Another app or agent the customer connected | Events and objects in a scope | |
| A widget | Your service’s UI, acting as the signed-in person | Recordings, uploads, form submissions | Onboard data with a widget |
| Your own app | A web, mobile, or server app with the Vault SDK, under the person’s key | Events and objects | Onboard from your app |
| A connector | Slack or Telegram, through a vault connection | A message event that can start a workflow | Connectors |
| A webhook | An outside system calling a workflow’s webhook URL with a key | A trigger event | Triggers |
| A server integration | Your headless process, under a delegation token | Events and objects, on a schedule | Build a vault integration |
Already there
The data may already be arriving, written by an app or agent the customer
connected earlier. A health app writes heart-rate readings into the customer’s
health scope; your coaching workflow reacts to them. You never talk to the
watch and hold no integration credential.
A widget
A widget is your service’s UI in the browser. It acts as the signed-in person, so what it writes lands under their own authority. Use it when onboarding belongs inside your product’s own screen.
Your own app
An app you already ship can write into the customer’s vault through the Vault SDK: publish events, upload objects. It signs with the person’s key, so the vault authorizes the write because it descends from their wallet.
A connector or a webhook
Outside systems can push straight into a vault. A Slack or Telegram message arrives through a vault connector; any other system can call a workflow’s webhook. Either can start a run.
A server integration
A headless process can sync a source into the vault on the customer’s behalf, with a scoped, revocable delegation token instead of their key.
What agents make of it
Once data lands, your agents and workflows turn it into two kinds of output:
- Working state in your service’s cubbies.
- Durable conclusions in the vault’s Memory Bank, privacy-classified and kept by the customer.
Compute does not depend on the route
| Route | What your agent does |
|---|---|
| Already there | Reacts to events in the scope |
| A widget | Reacts to the events the widget published |
| Your own app | Reacts to the events your app published |
| A connector or webhook | Runs from the trigger event |
| A server integration | Reacts to the events it published |
The last column barely changes. The vault is the interface between onboarding and compute: an agent written for heart-rate events does not know whether they came from a watch app, a widget, or your server.
Give each source its own scope and stable, namespaced event types
(health.heart_rate, health.steps), so the customer can connect an agent to
exactly that data and the payload shape stays a contract.