Compliance

Socure in a decision flow.

A Connection node calls Socure 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: Compliance
Type: Integration
Authentication: api_key
Test environment: Separate sandbox host

What a flow can call

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

POST/api/3.0/EmailAuthScore
Verify identity and score fraud
The main ID+ call. The endpoint name is legacy — the modules array is what decides the work.
POST/api/3.0/EmailAuthScore
Screen against watchlists (AML)
Sanctions, enforcement, PEP and adverse-media screening.
GET/api/3.0/transaction?referenceId=$data.socure_reference_id
Re-read a past transaction
Replays a completed transaction by the referenceId the original call returned.
GET/api/3.0/reasoncodes
List reason codes
Every reason code and its meaning. Worth calling once to build a local lookup so a decline reason renders as words rather than as R185 — adverse-action notices need the words.
POST/api/5.0/documents/request
Start document verification
Predictive DocV — starts a session where the applicant photographs an ID and a selfie.

Provider documentation: https://developer.socure.com/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 Socure returned at the time is in the trace, not re-fetched from a service whose answer has since changed.