Skip to main content
LendAPIField Guide

Appearance

Updated Oct 16, 2026

Offer tables ​

Offer tables are the pricing grids the pricing engine uses to turn an applicant’s numbers into a rate, term, and amount. Instead of hard-coding a rate for every FICO band and term combination, you build the grid once, and the engine looks up the matching cell whenever it prices an application.

What’s in an offer table ​

Each table has:

  • Name — how it appears in the list.
  • Type — set when you create the table, either parent or child.
  • Version — a number that increases each time you publish changes.
  • Published status and Active status — two separate flags (see below).
  • Last updated timestamp and the name of who created it.

The table list can be searched by name and filtered by status or type, so you can find a specific pricing grid quickly in a tenant with many products.

Viewing offer tables ​

  1. From the sidebar, open Pricing Engine.
  2. The list shows every table: name, version, type, published status, active status, last update, and creator.
  3. Use the search box to find a table by name, or filter by status or type to narrow the list.

Creating an offer table ​

  1. On the Pricing Engine page, click Create.
  2. Enter a name, choose a type (parent or child), and add a description.
  3. Save. The system creates the table and opens it in the editor so you can build out the grid. You’ll see a confirmation that the pricing engine was created.

Creating a table does not affect live applications until you publish a version and activate the table.

Building the table ​

The editor for a table is organized into sections:

  • Details — name, type, description.
  • Input Mapping — the applicant and loan variables the table reads (for example, FICO score, requested amount, requested term).
  • Output Mapping — the values the table hands back to the rest of the pricing engine (for example, rate, term, approved amount).
  • Derived Mapping — additional values worked out from the mapped inputs and outputs.
  • Trigger — conditions attached to the table.
  • Test Inputs / Test Outputs — where you preview the table before publishing (see Testing, below).

The grid itself is a spreadsheet. Each cell is one of a few types: a plain input, a dropdown (for picking from a fixed list of values), a variable reference, a label, or a corner label that marks the direction of a header (for example, a FICO-band axis running down the rows and a term axis running across the columns). Dropdown options in the grid are populated automatically from reference data the editor loads for you. The toolbar lets you import and export the grid.

Depending on how you set up a column, the editor formats the value for you automatically — as a dollar amount with thousand separators, or as a percentage — so you don’t have to type currency symbols or percent signs into every cell.

Editing an offer table ​

  1. Open the table from the list.
  2. Change the details, mappings, trigger, or grid contents.
  3. Save. Editing updates the draft copy of the table; you’ll see a confirmation that the pricing engine was updated. The draft is not what applications are priced against until you publish it.

Testing an offer table ​

Before you publish changes, you can preview how the table would price an application:

  1. Open the Test Inputs section and enter sample values for the mapped variables (for example, a FICO score and a loan amount).
  2. Run the test. The engine evaluates the table — either your current draft or a specific saved version — and shows the resulting outputs in Test Outputs.
  3. Adjust the grid and re-test as needed. Testing does not affect live applications.

Versioning and publishing ​

Every time you publish, the table gets a new version number. When you publish:

  1. Open the table and make your changes in the editor.
  2. Click Publish.
  3. Enter a description for this version (use it to record what changed, for example “Q3 rate update”).
  4. Choose whether this version should become the default — the version the pricing engine actually uses.
  5. Confirm. You’ll see a confirmation that the pricing engine was published.

You can also view version history for a table: each entry shows the version number, its published description, when it was last modified, who created it, and whether it’s the current default. You can change which version is the default without publishing new changes — open the version list and set a different version as default. You’ll see a confirmation that the default version was updated.

Activating and deactivating ​

Separately from publishing, a table has an active/inactive status that controls whether it’s in use at all:

  1. Open the table (or use the status control from the list).
  2. Toggle the status to Active or Inactive.
  3. You’ll see a confirmation that the status was updated.

An inactive table is not used to generate new offers, regardless of what’s published. An active table uses whichever version is currently marked as default.

Deleting ​

Deactivate a table before considering deletion, and confirm no live product or rule configuration still points to it. Deleted tables cannot be recovered. (This behavior is carried over from earlier documentation and has not been re-verified against the current system — confirm current delete behavior in your environment before relying on it.)

Worked example ​

A tenant admin at a credit union needs to update the pricing grid for a personal loan product ahead of a rate change.

  1. The admin opens Pricing Engine and searches for “Personal Loan APR Grid,” a parent-type table currently active at version 3.
  2. They open the table and edit the grid: rows for FICO bands (580-619, 620-659, 660-699, 700-739, 740+), columns for term (36, 48, 60 months), with each cell holding an APR percentage. The percentage columns display with a % automatically because of how the columns are typed.
  3. In Input Mapping, the applicant’s FICO score and requested term are already mapped from the application. In Test Inputs, the admin enters FICO 700 and term 60 and runs a test. Test Outputs shows an APR of 14.99% — matching the intended cell in the grid.
  4. Satisfied with the result, the admin clicks Publish, enters the description “Q3 2026 rate update,” and checks the option to make this the default version. The table becomes version 4, marked as default.
  5. Because the table’s status is already Active, the pricing engine immediately starts using version 4 for new applications. No separate activation step is needed since the table was already active — only the default version changed.

Use case ​

A credit union wants to roll out a quarterly rate refresh without disrupting applications that are already in progress. Instead of editing the live table directly, an underwriter builds and tests the new rate grid as a draft, checks the numbers with the Test Inputs/Test Outputs panel using a few representative applicant profiles, and only then publishes it as a new version and sets it as default. Applications already priced under the previous version keep their existing offer; only new applications get the refreshed rates.

Best practices ​

  • Test a table with a handful of representative FICO bands and terms before publishing — the Test Inputs/Test Outputs panel lets you do this without affecting live applications.
  • Write a clear description every time you publish. Version history is only useful later if the descriptions explain what changed.
  • Use the “set as default” option deliberately. Publishing a new version does not require making it the default; you can publish a version and switch to it later once you’re ready.
  • Deactivate a table you’re retiring rather than deleting it right away, so you keep the option to review its history.
  • Don’t rely on editing a table’s draft as a way to change live pricing — the draft only takes effect once you publish it and, if needed, make it the default version.

Unclear / not verified in current source ​

  • The functional difference between a parent-type and a child-type offer table.
  • What conditions or logic the Trigger section actually controls.
  • The precise mechanics of the Input Mapping, Output Mapping, and Derived Mapping sections beyond mapping variables in and out of the table.
  • Whether only one table per product can be active at a time, and what happens to a previously active table when another is activated.
  • Delete behavior: whether deletion is currently possible, and what dependency checks (if any) the system performs before allowing it.
  • What error message or behavior appears if a test/analyze run fails (for example, missing required input variables).
  • What happens to an application mid-decision if the default version changes while it’s being processed.

LendAPI Field Guide.

Copyright © LendAPI