Push your records to a hosted field

A hosted DIN field keeps your records on our servers and gives you a dashboard and an agent read door for them, reachable from anywhere. Capture and grading still happen on your own machine, with your own model key: DIN never runs inference for you. Your install produces the records, and din hosted push sends them up.

DIN is prelaunch and no hosted plan is on sale yet. This page documents how the commands work for when they are.

What you need

A hosted DIN console address (for example https://din.example.com), from your hosted plan.
An agent token for that console, saved in a file only you can read.
curl on the machine that pushes. din hosted talks to the console through it.

Put the token in a file and make it private. The file holds one line: either the token alone, or name:token, the same format the console's own token list uses.

printf 'laptop:%s\n' '<AGENT_TOKEN>' > ~/.din-hosted.token
chmod 600 ~/.din-hosted.token

A token file that other users can read is refused.

Connect

din hosted connect https://din.example.com --token-file ~/.din-hosted.token

This checks that the address is a hosted DIN console and that it accepts the token for a read. It then saves the address and the token file's path in <prefix>/.din/hosted.env (mode 600). The token itself is not copied anywhere. It is read from its file on each call and handed to curl on stdin, never on its command line, so it does not show up in a process listing. din hosted never prints it.

Only https:// addresses are accepted. The one exception is http:// to this machine (127.0.0.1 or localhost), because anywhere else plain http would send the token unencrypted.

Push

din hosted push --dry-run      # count what would be sent; sends nothing
din hosted push                # send everything stored since the last push
din hosted push --since 2026-09-01

A push reads the records this install has stored, the same store the capture plugin writes to, through the store's own MANIFEST.jsonl. It sends them 100 at a time. Each record is sent exactly as it is stored, with its store id added. For each record the console answers one of three things:

new: it is now on the hosted field.
unchanged: it was already there. Pushing the same record twice never makes a second copy.
refused(<reason>): it was not stored, and the push says why. invalid means the local store's own rules reject it. regime means its grade has no code on the hosted field. cap means the field is full. door means the hosted service could not be reached.

The push remembers how far through the manifest it got, so the next push sends only what is new. It stops at the first cap or door refusal and keeps that record and everything after it for the next push, so nothing is skipped. --since sends everything stored from that date or time again. Records already on the field come back unchanged, and a --since push does not change where the next ordinary push starts.

A hosted field holds a fixed number of records, set by its plan. din hosted status shows how many it holds against that cap.

Keep it current

Nothing pushes on its own. Pick one of these:

Run din hosted push yourself when you want the hosted field current.
Schedule it. With cron: */30 * * * * din hosted push >> ~/din-hosted-push.log 2>&1. On Windows, add a Task Scheduler task that runs din hosted push.
Push at login. din autostart on --with-push starts the field at login as din autostart on does, and also runs din hosted push. It needs din hosted connect first. din autostart off removes it.

Status and recall

din hosted status
din hosted recall "journey planner latency"

status shows the console address, the token file's path, when the last push ran and what it sent, how many local records have not been pushed yet, and how many records the hosted field holds against its cap. recall asks the hosted field with the same token and prints each hit with its grade and a short excerpt.

For agents calling the console directly

Every /api/* route on a hosted console except the health probe /api/healthz needs Authorization: Bearer <agent token> (or, for reads, the browser session described below). Without either the answer is 401 with WWW-Authenticate: Bearer realm="din". A token that is sent and wrong is a 401 even from a signed-in browser.

GET /api/recall?q=<words>&k=<n> for recall.
GET /api/query?... for filtered rows.
GET /api/record/<seq> for one record, body included.
POST /api/records writes one record (a JSON object) or a JSON array of up to 100. The answer lists, in order, each record's id, its status (new, unchanged or refused) and, when refused, its reason and detail. A record pushed this way needs "id" set to its store id, which din hosted push adds for you. Only an agent token writes: a browser session gets 403 here.

The dashboard

The hosted dashboard is opened from your customer portal, not with the agent token. Sign in to the portal and choose "Open your hosted DIN". The portal hands your browser a one-time sign-in link, and the console sets its own session for 8 hours. After that, open it from the portal again. Opening the console address directly without a session shows a page that sends you to the portal.

The session lets you read everything the dashboard shows. It does not write records; din hosted push does. An agent token opens the /api/* routes, not the dashboard pages.