Identity verification
Footprint in a decision flow.
A Connection node calls Footprint 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
- Identity verification
- Type
- Integration
- Authentication
- api_key
- Test environment
- Production host only
What a flow can call
2 operations, each one a step you can place on the canvas.
- POST
/onboarding/sessionStart an identity-verification session
Creates a short-lived token for Footprint's browser or mobile SDK.
- GET
/users/$data.footprint_user_idRead an identity-verification result
Reads the current status for a Footprint user. A pending or manual-review result is not a pass; accept the final outcome via a verified Footprint webhook or this follow-up call.
Provider documentation: https://docs.onefootprint.com/articles/integrate/onboarding-sessions
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 Footprint returned at the time is in the trace, not re-fetched from a service whose answer has since changed.
- 01Add Footprint as a connection, with your credentials.
- 02Place a Connection node and choose the operation.
- 03Read the response in the rules, tables and branches that follow.
- 04Test the whole path in Sandbox before it carries live traffic.
Also in Identity verification
GBG Go
SumsubReady when you are
Wire Footprint into a real decision.
Build the flow in Sandbox, connect your account, and watch the decision pull what it needs before it answers.