Webhooks at the Loan Level

Complexity:    

Audience: Loan Servicer or Collector, Upper Management, Developers, Loan Servicing/Collections Managers, Administrator, Data

Introduction

As we explain in our Notifications – Webhooks article, webhook history can be viewed at the loan level. A loan's webhook history information is stored within the Notes/Alerts section of the Servicing tab, as it is here that you can view historical changes to a loan's account.

In this article, we'll explain the webhook information presented here. If you'd like a refresher on webhooks as a topic, take a look at our Webhooks 101 article. We recommend being familiar with the webhook functionality included in LoanPro's settings before reading this article. If you need to brush up on that information, read through our Notifications – Webhooks article first.

Loan-Level Webhook Information

To view a loan's webhook history, navigate to Servicing > Notes/Alerts and then the Webhooks tab within a loan account.

This page displays all of the webhook activity for the loan, and each line is an individual webhook sent by the system. On this page, you can also view and filter the webhooks that have been sent. Let's break down what each column on this page means.

Column Name

Description

ID

This is a unique identifier that is used by the database to store webhook information. This ID changes each time a webhook is retried.

Trace ID

This is a unique identifier that is simply used by the system to track a webhook. LoanPro creates this automatically, and it has no effect on the webhooks themselves. This ID remains the same even if the webhook is retried multiple times.

Event Title

This is the name of webhook that was sent by the system.

Method

This determines what the system does with the information in the webhook. Different methods do different things:

  • GETs pull information
  • POSTs create new information
  • PUTs update existing information
  • DELETEs remove information

Response Code

This is the response code that was received by the system. Like response codes provided by the LoanPro API, successful responses are typically a 200, and unsuccessful responses fall in the 400s and 500s.

Time Stamp

This is the time that the webhook was sent out by the system.

# Attempt Number

This is the attempt number of the webhook that was sent by the system. Unsuccessful webhooks can be configured to be retried, resulting in multiple attempts.

You'll notice that the number of attempts for a webhook starts at "1", and once a webhook is retried for the first time, the number of attempts will show "2". The system counts the initial webhook as the first attempt. So, for example, if your webhook is successful on the third retry, this page will show the # of attempts as "4".

You can also expand a webhook's information to view greater detail. To expand a webhook, click the blue arrow icon located on the right.

A few additional details will be displayed in the expanded view. Here, you can view the IP address it was sent from, its destination, the response time, and you can download the source and response payloads.

Lastly, you can view if a webhook was manually retried. You'll notice here that you can resend a webhook via the 'Resend' button. This is the only location within the software that you can manually resend webhooks, but you can also resend them via the API if you'd prefer. This is designed to be a true retry of the webhook that was sent. Other than the value of the attempt number (which will change to "manual" instead of a number), the payload of the manually resent webhook will be identical to the original—even if the values of the loan have changed in the meantime.

More details on manually resending webhooks
You may be wondering why the payload remains the same during a manual resend. The main use case for manually resending webhooks applies to situations where the receiving system of the webhook is having processing issues but still responds to LoanPro with a 200 response. In this case, the webhook would need to be resent exactly as it was initially for the event to reprocess.

However, the other common use case occurs when the receiving system of the webhook responds with something outside of the 200 range (which would be deemed a failure), and the system can't be fixed before the automatic retry timeframe runs out. In this case, the user would then manually retry the webhook when the receiving system is operational and ready to process events.
A manual retry does not "reset" the automatic retry mechanisms. For example, if a webhook with a 5-minute retry time receives a 400 response, but a manual retry is sent within 2 minutes, the system will still send out the automatic scheduled retry at the 5 minute mark from the original failure happening.

If you resend a webhook manually, new webhook history will display on this page; however, you'll notice that the Trace ID of the webhook will be repeated. Here's an example of this in action:

The webhook with the Trace ID of ff74d2b1-660f-4d47-bc79-143cffab0903 was resent twice within this loan's record, and you can tell that both attempts were successful on their first try by the "200" response codes and the attempt numbers remaining at "1".

Common Questions

Can I manually send a new webhook from this page? No, you can only manually resend a webhook that has already been attempted by the system.

Terminology

Here are some common terms that are used when discussing webhooks:

Term

Definition

event

In the context of webhooks in LMS, an event is a change that is made to a loan. LMS provides event-based webhooks as a form of change criteria. Examples of events are loan status changes, payments, modifications, etc.

trigger

In the context of webhooks in LMS, a trigger is a custom-made criteria that looks for a change made to a loan. Trigger-based notifications allow users to set Clojure formulas for flexible and customizable criteria.

webhook/callback URL

This is the URL that you tell your webhook to send information to in the form of a payload. LMS provides a way for users to set this within the UI.

method

This determines what the system does with the information in the webhook. Different methods do different things:

  • GETs pull information
  • POSTs create new information
  • PUTs update existing information
  • DELETEs remove information

payload

A payload is set of text that a webhook generates when you receive a response. This holds the information that your request asked for. Similar to responses you would receive from sending a request to our API, they are typically in a JSON format.

retries

When a webhook receives a failure response, it is retried after a specified amount of time. We go into more detail about this topic in our Notifications – Webhooks article.

timeouts

Timeouts tell a webhook to give up on its request if it hasn't received a response after a specified amount of time.

trace ID

This is a unique identifier that is simply used by the system to track a webhook. LoanPro creates this automatically, and it has no effect on the webhooks themselves. This ID remains the same even if the webhook is retried multiple times.

What’s Next

This is the end of the line for our webhooks articles. This is the last stop, but you're free to head back to the previous articles such as Notifications – Webhooks and Webhooks 101. If you're interested in learning how to manually resend webhooks via the API, take a look at our Resend Webhook article within our developer documentation.


How did we do?


Powered by HelpDocs (opens in a new tab)