Banking

LoanPro in a decision flow.

A Connection node calls LoanPro 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.

GET/odata.svc/Loans
List loans
Loans on the tenant. This is an OData surface, so filtering, paging and field selection are query parameters on the node — $filter, $top, $expand — rather than a request body.
GET/odata.svc/Loans($data.loanpro_loan_id)
Get one loan
One loan by id. Note the OData key syntax — the id goes in parentheses, not after a slash.
POST/odata.svc/Loans
Create a loan
Turns an approval into a serviced loan. The shape below is the minimum spine — displayId plus the LoanSetup terms; a real tenant usually requires more, and the required set depends on how the account is configured.
GET/odata.svc/Customers
List customers
Customers on the tenant. Use $filter on the node to look one up by email or SSN-last-four before creating a duplicate.
POST/odata.svc/Customers
Create a customer
Creates the borrower record a loan attaches to. Search first — LoanPro will happily hold two customers with the same person's details, and merging them afterwards is manual work.

Provider documentation: https://developers.loanpro.io/reference/loanpro-api-introduction

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 LoanPro returned at the time is in the trace, not re-fetched from a service whose answer has since changed.