Thank you for your interest in LoanPro. There are more articles in our knowledge center than are currently available to you. To view all content, please log in.

Home

Intro to APIs

This article explains APIs in layman’s terms.

Table of Contents

Complexity:    

Audience: Upper Management, Developers, Administrator, Compliance, Data

Introduction

This article explains APIs in layman’s terms. If you’re totally new to the concept, you’re in the right place. Developers and other tech-minded people probably won’t need this primer, and can skip ahead to Connecting to the API or our API Documentation.

What’s an API? And how does it compare to a user interface?

When you log in at loanpro.io and use the Loan Management System User Interface (LMS UI), you manually click buttons and type information to interact with the software. When creating a new loan, for instance, you’ll click through different screens and enter loan information. The LMS UI looks nice and is easy to navigate, because it was designed with human users in mind.

But let’s say we want to automate things. For example, lots of lenders want to automate the loan creation process. Let's say a lender gathers borrower information through their own web application. Using the LoanPro API, the web application could use the data to directly create loans in LoanPro. Because computers, rather than humans, will create the loans, there's no need for a modern and intuitive interface. All the computer needs to know is what data to send and where to send it. That’s where the API comes in.

The LoanPro application programming interface (API) provides a way for outside software to communicate with LoanPro. When an application communicates with LoanPro via our API, rather than manually clicking ‘New Loan’ and typing in loan data, data is sent in a bundle to a specific destination (called a URL, endpoint, or URI). LoanPro will receive that information and use it to create a new loan, then send back a response to confirm that the loan creation was successful. 

The API is designed to receive requests that create, update, delete, or retrieve data. This can be helpful when automating lending processes. Virtually any customer or loan data can be created, deleted, read, or changed through the LoanPro API. Many lenders choose to create custom software applications that directly integrate with LoanPro and other company systems, so data can easily be exchanged and kept in sync between them.

Interacting with the API

APIs are meant to let computers talk to other computers. On LoanPro's end, the software is ready. But it will take some effort to configure your own software or custom application to send the correct messages to the correct places. A team of developers can help set everything up so that your system can send and receive information from LoanPro through the API.

REST Clients

To set up and test the API, individual users can interact with it as well. Instead of logging in at loanpro.io, you'll need to use what's called a 'REST client'. This is a third-party application that can send and receive messages with LMS through the API. When your developers integrate your system with LoanPro's API, they won't use a REST client, and messages will be sent directly from your software to ours. The REST client is like a public computer at the library: It's useful if you just want to see how things work, but you wouldn't manage your business from one.

REST?

The LoanPro API is a Representation State Transfer (REST) API. REST is a set of constraints on the API that govern how it works and simplify the process for users. Your developers might need more information, but for the purposes of this article, we can just say that there are different kinds of APIs and LoanPro uses a REST API.

 
 

There are lots of different REST clients out there, and many are free. Insomnia and Postman are both highly rated and free to download.

Terms

Before we dive in and send some messages to the API, it'll be helpful to explain some specialized terminology.

Term Definition
Tenant

A tenant is your account with LMS. Normally we'd call this an "account" or "user," but both of those terms refer to something else in the software. Additionally, any number of agents can be users with the same tenant; they all share the same credentials to use the API.

 

Each tenant has its own database. Your data is your own, and no other LoanPro customer can access it.
Call / Request A call or request is your message to the API. The request has several parts, like an endpoint, payload, header, body, and method, which are all defined below.
Endpoint

When you send information to the API, you need to send it to a specific place. These are endpoints—URLs that tell the system exactly where you want to send or retrieve information. Each API request, like creating a loan or creating a customer, has its own endpoint. Some API endpoints, like the one used to create a payment, use the Loans endpoint, but the payload is specific to the action being done. There are also endpoints for specific entities, like an individual customer or loan.

 

Some endpoints exist, but are only available within the software and are used by LoanPro's interface. They are not "whitelisted" for use by external API users. These are mostly settings-related endpoints.
Payload / Body

The payload or body is the content of your request. Generally, requests that add or update content will include a payload, but requests to retrieve or delete information will not (see Method below for a fuller explanation).

 

The LoanPro API uses the JSON format, which is easy for humans to read and understand. This will help you or your developers figure out what information needs to go where, or diagnose the problem if something is wrong.
Headers

In the same way that the header on any document might tell you what it is, the headers of a request specify things about the request. For example, if your request includes a body (sometimes called a payload), a header can be included that specifies the format (for LoanPro requests, this is almost always JSON).

 

Your headers will also include authorization information. The authorization 'token' LoanPro uses is string of numbers and letters that's unique to your LoanPro account. In the same way that you'd have to log in with a username and password to use the UI, you'll need to include your token to use the API.

 

These tokens are stored in the LMS UI. Navigate to Settings > Company > API > Overview. Our Connecting to the API article explains the details.
Method

The method tells our system what you want to do. The LMS API uses GET, POST, PUT, and DELETE methods.

 

  • GET – You'll send this request when you want to retrieve information. GET requests do not contain a body.
  • POST – Much like posting something on a social media site, a POST request adds new content to the system. This might be creating something, or prompting the system to do something (like sending an email to a borrower or generating a report). POST requests will always have a payload.
  • PUT – Where POST requests often create something new, PUT requests will modify something that's already there. In the same way that you can log in to the UI and edit a customer's information, for instance, you can do the same through the API. PUT requests also contain a body.
  • DELETE – As the name implies, DELETE requests will remove something entirely from the system. Like GET requests, they have no payload.
Response

So far, everything in this table has been part of the request, part of your message to the API. The response is LoanPro's answer. Most REST clients will display the response right beside or below your request. The response will always include a three-digit number (called a 'status code' or 'error code', discussed below) that tells you whether the request was successful.

 

Usually, the response will also include a message about what the outcome was. If you created a loan or customer, it'll give you all of that entity's information. A successful GET request will pull all the information about the entity you're asking after, and the response can be rather long. A simpler request, like a DELETE, might just give you a single line saying that the item was deleted.
Status Code / Error Code

Every response from the system includes a status code, a three-digit number telling you whether the request was successful. A successful request will always give you a 200 status code.

When the request fails, the status code will usually be in the 400s. These are commonly referred to as error codes, and can be used to diagnose what went wrong with the request. If you've ever clicked an outdated link and seen a message that says "404: Page Not Found", then you've seen an error code first hand.

 

For security reasons, we can't publicly list what all of the error codes mean, but our API – Error Responses explains the basics. If you encounter an error code that isn't listed here, you can contact our support team.

 

Sample Request and JSON Payload

Now that we've gone over the basics, let's look at an actual API request. This is the request to create a new loan. 

Method and Endpoint

The POST method tells the system that we're adding new information. The loans endpoint is used for many of our API requests.

POST https://loanpro.simnang.com/api/public/api/1/odata.svc/Loans

Headers

The content-type header tells the system that your payload is in the JSON format. The Authorization and Autopal-Instance-Id are the tokens specific to an API tenant. These tokens connect you to our demo API tenant, but our Connecting to the LoanPro API article explains how to find the tokens for your own.

Content-Type: application/json
Authorization: Bearer {token}
Autopal-Instance-Id: {Tenant ID}

JSON Payload

This payload has only the required elements—it's the bare minimum for creating a loan. For a more robust payload with all the available options, see our Create a Loan API reference page.

{
     "displayId": "L-z0k748522154",
     "LoanSetup": {
          "loanClass": "loan.class.carLoan",
          "loanType": "loan.type.installment",
          "loanAmount": 15000,
          "loanRate": 12.0212,
          "loanRateType": "loan.rateType.annually",
          "loanTerm": 36,
          "contractDate": "2021-05-12",
          "firstPaymentDate": "2021-06-11",
          "paymentFrequency": "loan.frequency.monthly"
     }
}

Let's take a closer look at this payload. One of the first things you might notice are the { } curly brackets at the beginning and end of the payload. A pair of brackets show that everything within them is connected; all these values are a single object. This outermost layer of brackets tells the system where your message begins and ends.

You'll also notice that every line has two parts, separated by a : colon. This is called a name/value pair, or key/value pair. The name is on the left, surrounded by " " double quotation marks. The name defines the pair, like a label on a jar. The value, on the right, is like the contents of the jar. For example, "loanAmount" is a name; it defines this pair as the amount of money borrowed. The value, 15000, means that the borrower took out a loan for $15,000.

The value is flexible—a borrower could just as easily take out a loan for any other amount. The name, however, is not flexible. It must be written exactly. It needs to be in double quotation marks, be written in the exact same case, and have no extra spaces or dashes. The system will not understand any change to a name.

Looking closer, you'll see another set of brackets, opening after "LoanSetup" and closing after "paymentFrequency". You'll also notice that from the third line down, all the new lines are indented. The brackets and indentation are ways of showing that all of those name/value pairs (from "loanClass" down to "paymentFrequency" ) are part of an object; they are all a single value, in a pair within "LoanSetup".

The brackets are an essential part of the JSON payload: Without them, the system will not understand that the name/value pairs within the brackets are part of a larger object. The indentation, however, is not required. New lines and indents are just 'white space,' meaning they don't add any meaning or interrupt the payload. If a computer is sending this API request to another computer, they'll probably send it without any new lines or indents. When humans look at JSON payloads, we usually add white space to make it easier to read and understand. There are lots of websites that can add white space and 'prettify' payloads. 

This Feature Is Not

Now that you have a pretty good idea of what an API is and and how they work, let's clear the air about some common misunderstandings.

  • An API is not just a cooler way for an individual to use the software. Yes, it sounds cool to say "send the payload," and you'll probably feel like a genius now that you know what a 404 error means. However, we ought to stress that APIs are designed to be used by other software, not by humans with REST clients. If you really want to do all your servicing through Postman or Insomnia, I guess we really can't stop you, but you'd be making things a lot harder than they need to be.
  • An API is not an import. Imports let you move large amounts of data into the system quickly by circumventing the UI, which admittedly is a pretty apt description of what the API does as well. However, these are two very different tools. Our Import vs API: What's the Difference? article answers the question in its title.
  • APIs don't build themselves. Building and maintaining an API is a full-time job, and that goes for both our team and yours. Integrating with the LMS API will most likely require a dedicated tech team, and should be a major consideration as you consider using the API.

What's Next?

From here, you can dive into our entire library of API documentation, which is found in two places. One is help.loanpro.io, the site you're on now, which houses our LMS API and Secure Payments API directory articles as well as over a thousand articles detailing how to use all of our products. 

The other site, developers.loanpro.io, is dedicated solely to API documentation. Each article here contains endpoints, headers, payloads, and responses (200s and error codes). These articles also feature a 'Try it' button that allows you to try individual API request yourself.

basics apis authorization type

Written by Jackson Stone

Updated on June 13th, 2024

Have Questions?

Contact Us