Skip to the operations

Banking

LoanPro in a decision flow.

5 LoanPro operations a decision flow can call directly, with the credentials your own contract issued. The response is data the rest of the flow reads, branches on, and keeps in the trace.

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

Who they are

Loan management and servicing in the cloud.

LoanPro holds accounts, schedules, balances and payments after a loan is originated. Where it is the system of record, an approval is not real until the loan and the customer exist in it — and its read side is what a refinance or cross-sell decision consults for current position.

What a flow can call

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Where it sits in the decision

Banking calls have a natural place in a flow.

Bank data answers the question a stated income cannot: what actually arrives, how regularly, and what leaves again. It is usually pulled once per application and then read by several nodes — affordability, income verification, any rule about balance volatility — so it is worth fetching early and deriving from, rather than calling repeatedly.

Whatever LoanPro returns is part of the run, so it is part of the record. When someone asks months later why an applicant was declined, the answer cites what came back at the time rather than re-fetching from a service whose answer has since changed.

  • 01Add LoanPro as a connection authenticating with API key headers.
  • 02LoanPro has one host for both environments, so guard test runs with your own credentials and limits.
  • 03Place a Connection node and pick an operation — “List loans” is usually the first one a flow needs.
  • 04Map the response into the fields your rules read, then test the whole path before it carries live traffic.

Common questions

Using LoanPro in a flow.

How do I connect LoanPro to a decision flow?

Add LoanPro as a connection in your workspace authenticating with API key headers, with the credentials your own contract issued — ArboRule calls the provider as you, and never holds a contract on your behalf. Once the connection exists, any flow in the workspace can place a Connection node and choose one of its operations. The credentials live on the connection, not in the flow, so a policy owner can use LoanPro in a decision without ever seeing the secret.

Can I test LoanPro without touching production?

LoanPro exposes one host for both environments, so there is no separate sandbox to point at. Test runs still execute in Sandbox and are recorded separately in decision history, but the call goes to the same place as production — so guard it with your own test credentials, rate limits, or data.

What can a flow call on LoanPro?

5 operations, including “List loans”, “Get one loan”, “Create a loan”. Each one is a step you place on the canvas and map into the fields your rules read, and most flows start with “List loans”. The list comes from the same manifest the engine uses to make the call, so this page cannot describe an operation the product does not have.

Where in a decision should LoanPro be called?

Bank data answers the question a stated income cannot: what actually arrives, how regularly, and what leaves again. It is usually pulled once per application and then read by several nodes — affordability, income verification, any rule about balance volatility — so it is worth fetching early and deriving from, rather than calling repeatedly.

Also in Banking

Ready when you are

Wire LoanPro into a real decision.

Build the flow in Sandbox, connect your account, and watch the decision pull what it needs before it answers.

Read the docs