Benedict Servicing API

Your systems and your vendors, talking to Benedict directly

A small, modern HTTPS/JSON API that runs on your own servers beside your Benedict loan servicing system, so your applications and your vendors' applications read and update loan data directly instead of exporting files or re-keying screens. It applies every change with the same validation and audit trail as an operator, and returns plain-English, per-item results your integration can act on.

Talk to Us About Integrations Read the Documentation
Benedict Servicing LFN The proven desktop system your servicing team runs today — solid, complete, and fully maintained.
Benedict Servicing Pro The full browser-based successor to LFN — perpetual license, recurring releases. The path forward.
Benedict Servicing Starter A limited browser system for your back office — inquiry, dashboards, standard reports. Existing LFN clients.
Benedict Servicing Portal Strictly for borrowers, investors, and other third parties — self-service, no internal users.
Benedict Servicing API You are here An HTTPS/JSON API on your own servers so your systems and vendors talk to Benedict directly. First capabilities in pilot.

Runs on your servers

Installed beside Benedict on your own IIS. Your loan data never routes through Benedict Group.

Applies changes like an operator would

The same validation and the same change-audit trail as a person working in the application.

One API, many capabilities

Every capability shares one key, one set of conventions, and one documentation style.

How it is secured

Built for machine-to-machine use, where the simplest mechanism is the safest one.

  • One API key on every call. No login step, no tokens, no sessions to manage. Revocation is immediate.
  • Keys are stored only as a salted hash. PBKDF2-SHA256 at 210,000 rounds, checked in constant time. Your key is shown once, at issue; nobody at Benedict can read it back.
  • Plain HTTP is refused, not redirected. A failed authentication returns an empty 401 that explains nothing to an attacker.
  • Test keys work only on test; live keys only on live. A misconfigured staging server cannot touch production data.
  • Throttling before authentication, pacing per user after it. A 256 KB request cap, and five failed attempts on a key pauses further checks.
  • A capability you have not licensed does not exist, as far as the network can tell. Unlicensed routes answer the same way as routes that were never there.
  • Least-privilege database access. The API's login has only the columns and tables each capability needs. Every change writes Benedict's standard change-audit row in the same transaction as the change.
  • Logs never contain loan numbers, names, amounts, or policy numbers. Raw errors never reach a caller.

How it grows

The platform is built once. Each new capability is business function on top of it.

A capability adds business function only

Never a new way to authenticate, a new error style, or a new connection pattern. Your integration code for the next capability looks like the last one.

Your build contains only your capabilities

Capabilities and seat count are compiled into your delivery. Changing your package is a rebuild, not a server-side switch.

Versioned from the start

Everything lives under /v1. A breaking change is published as /v2 beside it, and /v1 keeps working.

Capabilities that calculate, such as amortization schedules, call the same engine the desktop and browser systems use, so the numbers match what your staff see on screen.

Available now and next

Phases, not dates. We say "on the roadmap" until it ships.

In pilot with the first client

Insurance renewal

Submit a reviewed renewal, single or batch, with per-item results and a dry-run mode.

Available

Seat status

Ask how many API seats are licensed, in use, and free, so your code can plan instead of guessing.

Rolling out

Amortization schedule

Schedules from the same calculation engine the desktop and browser systems use, so the numbers match.

On the roadmap

Borrower statements and prepayment calculation

On the roadmap

Payoff quote and escrow analysis

Installing it

  • Your Windows server, IIS, and the .NET Hosting Bundle
  • An HTTPS binding with a certificate your callers trust; plain HTTP is refused
  • Separate test and live instances, each with its own keys
  • Upgrades: replace the files and recycle the application pool

Licensing it

  • Concurrent API users, not per-call fees. A process is a user.
  • Your code can ask the API how many seats are free before it starts a run
  • Keys are issued by Benedict at setup and shown once
  • Capabilities and seats are part of your package; ask us to change either

Documentation

Written for the people who will build against it and the person who will host it. LNApi is the technical name of the Benedict Servicing API; the full set ships with your package.

Overview

What the API is, authentication, users and concurrency, errors, and versioning.

Installing the API

For the person hosting it on IIS: prerequisites, HTTPS binding, test and live instances, upgrades.

Insurance renewal

The first capability's contract: request and response shapes, dry run, batch limits, audit trail.

Ready to Transform Your Loan Servicing?

Tell us about your needs and we'll schedule a personalized demo.

I'm interested in:

What to expect

  • 30-minute personalized walkthrough of the platform
  • Discussion of your specific servicing workflows
  • Honest assessment of fit for your portfolio
  • No pressure — just a straightforward conversation

Prefer to call?

(303) 747-6690