Variables

A variable is a named piece of application data, such as annual_income, loan_amount or credit_score. Every value on an application is stored under a variable: answers the applicant types, results from integrations and values LendAPI calculates.

Each variable has a Variable Code, a unique, lowercase identifier. Product Studio fields, decision trees, pricing engines, email and SMS templates, and the API all use this code to read and write the value. You manage variables in Model Studio.

Variable basics

Variable sources

The Model Studio table groups variables by Source:

System default variables are the standard variables every workspace starts with: applicant details, application details, loan terms, workspace details and so on. In the table they carry the LendAPI logo and the tooltip "System Default variable".

Data types

Numeric and String variables also have a Display Type that controls formatting:

• Numeric: Regular, Money or Percentage. You can also set a Decimal Limit.
• String: Regular, Email, Phone, SSN, EIN or URL.

List variables have options. Each option has a value (what's stored and what your rules compare against) and a display value (what the applicant sees). A list can be Single select or Multi select.

Create variables

Create a variable

1. In the left sidebar, open Workflows → Model Studio.
2. Click + Variable.
3. Under Variable Source, choose User Input, Derived or System Output.
4. Fill in:
   • Variable Name: a readable name, under 100 characters.
   • Variable Code: the code used everywhere else. Use lowercase letters, numbers and _ only; it can't start with a number and can be up to 60 characters. Reserved words such as date, pi or Python keywords are not allowed.
   • Variable Type, Display Type and, for numbers, Decimal Limit.
5. Save. For a List variable, you are then asked to add its options. You can also upload options from a CSV file.

After you create a variable, its Variable Code can't be changed. Variables are never hard-deleted; set a variable's status to Disabled to stop using it.

Create a derived variable

A derived variable calculates its value from other variables using a formula.

1. Click + Variable, choose Derived, and enter a Variable Name and Variable Code.
2. Open the variable to reach Edit Derived Variable.
3. Type the formula in the editor. Use + Variable to insert another variable's code, and Validate to check the syntax.
4. Click Test to try the formula with sample values.
5. Click Save to save the draft.
6. Click Publish, enter a Changelog and tick Set as default version.

🚧

Only the default version runs

Applications always use the derived variable's default version, not the draft. A formula you have saved but not published, or published without Set as default version, has no effect on applications. A brand-new derived variable with no published version evaluates to empty.

Open the Versions tab of a derived variable to see past versions with their changelogs and to change the default version.

Write formulas.

Refer to other variables by their bare code. Formulas use Python-style expressions:

Useful built-ins include abs, round, min, max, sum, len, int, float, str, date, timedelta, relativedelta, today() and now(), plus standard math functions. In the editor, the link "Feeling stuck, learn how to create variable expressions, click here" opens the full in-app reference.

When derived values are calculated. Derived values are calculated whenever they're needed, for example when a decision tree or pricing engine runs. When you create an application through the API, add "recompute_derived_vars": true to calculate them at creation.

System default variables

These are some of the system default variables your workspace starts with. Some values, such as app_status, are calculated at the moment they're used rather than stored, so they're always current.

Use variables

Where variables are used

• Product Studio: each field is bound to a variable. Only active, published variables appear in the Variables palette.
• Decision trees: rule nodes compare a variable's value, for example credit_score >= 680. See Decision Trees.
• Pricing engines: inputs read variables; output cells write to System Output variables. See Pricing Engines.
• Email and SMS templates: insert a variable chip, which becomes {{variable_code}} in the message, for example Hi {{first_name}}. See Email and SMS Templates.
• Contracts: the same {{variable_code}} placeholders. See Contracts and E-Signature.
• API: the data object on create and update calls uses variable codes as keys.

Mask sensitive data

Turn on Mask Field for a field in Product Studio to hide characters as the applicant types. Masking applies to that variable across your workspace. Masked values show as ******** in the dashboard. Staff need the permission to reveal masked fields to see the value. SSNs are always masked.

Use the API

Create accepts name (up to 120 characters), engine_name (the variable code, up to 60 characters), type and an optional description. Through the API, type can be 1 Numeric, 2 String, 3 Boolean or 6 List. Create Date and JSON variables in Model Studio.

For a List variable, send list_values:

{
  "name": "Housing Status",
  "engine_name": "housing_status",
  "type": 6,
  "description": "Applicant's housing situation",
  "list_values": [
    {"value": "rent", "displayValue": "Rent"},
    {"value": "own", "displayValue": "Own"}
  ]
}

A variable code that already exists returns engine_name already exists. Please use another one. Variables created with a sandbox key exist only in sandbox.

Access and best practices

Permissions

Variables are managed under the Model Studio module. Users need Edit access to create, edit or publish variables. View access is enough to test a derived variable. See Roles and Permissions.

Best practices

• Name codes for the long term. Codes can't be renamed and are used everywhere. Prefer clear names such as monthly_housing_payment over mhp.
• Use System Output for calculated results, so pricing outputs are easy to tell apart from applicant answers.
• Publish derived variables with Set as default version when you want the change live, and use Test before publishing.
• Disable, don't repurpose. If a variable's meaning changes, create a new one and disable the old one. Rules and templates that rely on the old meaning keep working.
• Mask anything sensitive (account numbers, ID numbers) at the field level.

Related guides