Banking

Truv in a decision flow.

A Connection node calls Truv mid-decision with the credentials your own contract issued. Whatever comes back is data the rest of the flow can read, branch on, and keep in the decision's trace.

Category: Banking
Type: Integration
Authentication: API key headers
Test environment: Production host only

What a flow can call

5 operations, each one a step you can place on the canvas.

POST/v1/users/$data.truv_user_id/tokens/
Start a payroll connection (Bridge token)
First step. Mints the token that initialises TruvBridge for one user, who then picks their employer or payroll provider and logs in there.
POST/v1/link-access-tokens/
Exchange the public token
Second step. Bridge hands the front end a public_token; this trades it for the access_token and, more importantly, the link_id that every report call below is keyed by.
GET/v1/links/$data.truv_link_id/income-employment-reports
Get income and employment (VOIE)
The verification of income and employment for a completed link — pay rate, frequency and employment status straight from the payroll record.
GET/v1/links/$data.truv_link_id/employment-reports
Get employment only (VOE)
Employer, title, start date and status without the income detail.
GET/v1/links/$data.truv_link_id/statements
Get pay statements
Individual pay statements with gross, net and the earnings and deductions breakdown.

Provider documentation: https://docs.truv.com/api-reference

Where it sits in the decision

A provider call is a node, not a side effect.

The call runs where the policy needs it — after the cheap checks that might make it unnecessary, before the rules that depend on it. Calls that do not depend on each other run together rather than in sequence.

Because it is part of the run, the response is part of the record. When someone asks why an applicant was declined months later, what Truv returned at the time is in the trace, not re-fetched from a service whose answer has since changed.