LoanPro API Overview Part 1
The LoanPro API provides access to tons of great LoanPro features that you can use to cut down on your development. Features include Customer Communication, such as sending text messages, emails, and letters, as well as accurate APR and Discount calculations and everything in between. The LoanPro API is used for a lot of different things. Some people use it to show customers information about their accounts, like their payment amount or upcoming due dates. Others use it to automate their business using features such as automated payment processing and automated alerts. Others build entire applications on top of the API!
The LoanPro API is a Representation State Transfer (REST) API. REST APIs are based on the Hypertext Transfer Protocol (HTTP). HTTP is a way to send and receive messages over the web. When a client sends a message (called a request) to a server, part of that request is a request type (i.e. GET, POST, PUT, DELETE). The idea behind REST APIs is that the request type should tell the server the type of action to perform (e.g. to get data you use a GET request). LoanPro is built upon this idea, and so throughout the tutorials there will be references to sending a GET request or making a POST request; these references just refer to sending an HTTP request with the GET or POST type (respectively).
The LoanPro API is also based on the OData 3.0 specification (developed by Microsoft). OData specifies how to structure data that is sent between the client and the server. OData is very powerful and allows for accessing data based on its relationship to other data. The LoanPro API is built around the concept of data relationships, so OData is a good fit.
Best Practices for Using the API
- Always wait for a response! This seems like it goes without saying (how will you know if a request succeeded without waiting for a response?), but we’ve had so many clients who don’t do this and lose data because they don’t handle error responses from the server. This applies to all APIs that you work with, not just some of them.
- Always catch errors! This isn’t just errors from a server, but also runtime errors (e.g. network errors, file system errors, DB errors). Again, almost seems like it goes without saying, but a lot of clients run into issues because they don’t do this.
- Deal with errors and warnings. Quite often “handling errors” means a silent fail because programmers don’t know what proper handling should be. Show the response to the user? Log it? Retry? It’s best to understand the types of possible errors and come up with unique handling for each. Transaction warnings are received when submitted data may already be present in LoanPro. Transaction errors are received when data is malformed and needs to be corrected. Network errors mean that the network is down and requests should be retried once it’s restored. You should have a plan of action for the errors that you catch.
- Programmers, lenders, and accountants should communicate. Lending and accounting are not the expertise of programmers, just like programming isn’t what lenders are good at. The best integrations will be the product of all interested parties, not programmers alone. Most of the questions we are asked about the API are really about lending. Be open with your communication.
- Design for redundancy. LoanPro uses redundant backups and versioning of data. If you are keeping data outside LoanPro, or have servers in a single location, you could experience outages due to local disasters, power outages, etc. These possibilities should be accounted for and there should be a backup plan in case something goes wrong. Always respect Murphy’s Law.
Click here to go to Part 2.