Connections & status
Connections & status
List your connections
Returns every active connection your organization holds with the token’s
user — the recovery path when you did not store request_id at connect time.
Pending invitations are never listed: before consent there is no connection.
manifestVersion is pinned at consent — re-publishing a manifest never widens
a live connection; new asks require a new consent.
Per-slot status
This is the surface to drive your UI from: the connection’s effective state, the manifest’s presentation groups, the parties it asks about and who answers for them, and each slot with its grant status.
slotIdis the canonical address of an item — use it on every other route.kind/targetremain for display. Kinds areschema,personal_filesand — on a company subject’s slot —entity_files.verbssay what you may do BEYOND reading. Reading a granted item is what a connection is, so it needs no verb and an empty list is ordinary — the plain ask.filllets you list the slot’s candidates, attach one, or create a value in it;editlets you update or delete the granted document on the user’s behalf;keepmeans your organization holds a copy that survives revocation and receives later versions.multipleis the slot’s cardinality.false— the default — means the slot holds ONE standing grant: a later fill with a different resource replaces it (the person switching payout accounts is one act, not a revoke-and-reconnect).truemeans grants accrue — “list all your addresses”. Gate any “add another” affordance in your UI on it; on a subject slot the count is per answering participant (one per child or company, not one per slot).statusisgrantedorpending— nothing else.pendingis deliberately indistinguishable from “the user refused” and from “the user has no such data”. Do not build UI that treats pending as “exists but not yet shared”; render it as not provided with a way to fill it in-app. Status is a live reading, never a latch: a slot goes back topendingwhen the user deletes the resource that answered it, so re-read it rather than caching the firstgranted.subjectsis the ask,participantsthe answer.subjectslists the parties this manifest asks about beyond the account holder, each typedperson(with its kinshiprelation) orcompany;repeat: truemeans the user decides how many.participants— absent while nobody is bound — says who is actually cast: one entry per party, each a pairwise alias that is stable across your organization’s connections and meaningless to anyone else. The same alias comes back on every served record and on the subject’s candidates, so you can group a connection’s data by party without ever seeing a vault id. A subject slot stays a single item here whatever its cast:grantedmeans at least one party has answered; who, and how many, is visible throughparticipantsand per record when the slot is served. See Subjects: relatives & companies.verificationis assurance metadata about the current version of a granted item — what was checked, how strong, when. Never evidence, present on granted items only, and absent again the moment a new unverified version is written.stateis evaluated at call time against both clocks: the request’s state machine and the terms’ retention window. A connection past its retention readsexpiredand stops serving immediately.