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. Its newest capability, New Loan Setup, creates a loan in Benedict from one JSON document.
Easier integrations start with docs people can read
What you send, what happens, what comes back, and when it says no.
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. Your key is shown once, at issue. After that we keep only a slow, salted hash, so it cannot be read 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. Oversized requests are refused, and repeated failed attempts are paused.
-
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 is granted only what each capability needs. Every change writes Benedict's standard change-audit row in the same transaction as the change.
-
Logs are built to leave out loan numbers, names, amounts, and 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 the amortization schedule, run the same program the desktop and browser systems run, so the figures and the PDF match what your staff see on screen, and Benedict checks the API against that program before every delivery.
A new loan from one JSON document
Your origination system, your spreadsheet import or your vendor sends one file that describes a loan. Benedict creates it the way a person would on the New Loan screen, and does the follow-up keying in the same step.
You send one JSON document
The loan, its borrowers and its properties, with investors and reporting types when you want to set them; leave those two out and Benedict uses your company's defaults. A borrower or property already on file is sent by its code alone and linked as it is.
Benedict checks the whole file
Every call is a trial run unless you say otherwise. It checks the file against your company's tables and tells you exactly what it would create: which borrowers are new, which codes it would generate, which parts it would fill in. Nothing is written.
Then it creates the loan, or nothing
Send the same file with writes on and the loan is created as one unit, with the New Loan screen's defaults. If anything is wrong, nothing is written; there is never a half loan. The loan starts In Process, ready for the New Loan Process in Benedict.
You read one plain answer
A status, one line of reason, every problem at once naming the field it is about, what was created, and the same loan checks a person sees on screen after keying a loan.
Three endpoints
One loan, a batch of up to ten loans with one outcome each, and a catalog of your fields, widths, required flags, defaults and your company's codes, so your mapping is built from your data.
The same care as an operator
The same validation, the same generated codes, the same loan checks and the same change-audit trail as a person on the New Loan screen. An API user needs the same right to create loans.
Built against the trial run
A clean trial run is the contract: when writes are switched on for your instance, the same file creates the loan and nothing else in the answer changes.
What it does not do: activate the loan. Disbursing, allocating and starting the history is the New Loan Process in Benedict, a separate step. Loan numbers are always yours to supply, and must be new.
Where each capability stands
The platform is in pilot with its first client.
Insurance renewal
Submit a reviewed renewal, single or batch, with per-item results and a dry-run mode.
Seat status
Ask how many API seats are licensed, in use, and free, so your code can plan instead of guessing.
New Loan Setup
Create a loan from one JSON document: the loan, its borrowers, properties, investors and reporting types, written together or not at all, with a trial-run mode, a batch of up to ten, a catalog of your fields and codes, and the same loan checks a user sees on screen.
Amortization schedule
The PDF amortization schedule for one loan, produced by the same program and the same figures as the screen, returned in the response; the program's own reason when it declines.
Borrower's statement
The borrower's statement for one loan and one period, by the same programs as the screens: the text page for page as the screen prints it, or the PDF rendered from the program's own output and laid out as the screen's.
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
Talk to Us About Your Servicing
Tell us about your needs and we'll schedule a personalized demo.
What to expect
- 30-minute personalized walkthrough of the platform
- Discussion of your specific servicing workflows
- Whether Benedict fits your portfolio
Prefer to call?
(303) 747-6690