Read the KYB graph
Every entity this user owns — linked and unlinked — with the ownership edges, resolved documents and the flow’s status, in one request.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Headers
Response
Successful Response
The customer-facing view of one user's KYB graph.
Everything the KYB flow needs in one read, and nothing shaped like a
questionnaire: the client edits entities and edges, so that is what it is
given. The admin's richer, projection-shaped view lives in
:class:KybDraftResponse and is built by a different service.
KYC verification status.
not_started, requested, incorporating, pending, under_review, approved, rejected The entity the KYB application is about.
EVERY entity this user owns — the ones the ownership walk reaches and the ones it does not. Splitting them is what made half-linked people invisible to the client that created them; deciding what to show is the client's job, and it needs the whole set to do it.
Invited owners who have not consented yet. Only their HEVN login email and relationship status are disclosed.
Resolved documents (name, signed link) keyed by entity id. Each type is the slot the file is filed in, which is what the admin console and the submission gate read; a file filed in two slots is reported once per slot.
Company document slots the draft flow asks for. Jurisdiction-dependent — a US company is also asked for its IRS EIN letter.
Document types every shareholder needs. Enforced at submit, so a client that cannot read the list here can only discover it by being refused.
Whether Authorization to Act and Authority to Bind documents are required. False when the account email belongs to a director.
What submission is still waiting for: the required fields POST /kyb/submit enforces, plus the document slots it asks for but does not block on. Without it here the flow could only discover the gap by being refused.