This guide will cover the common patterns that CRM partners use to integrate with Blend, and point you to all the resources you need to enact those patterns for your CRM.
There are 2 main patterns for CRM integrations:
- One-way to Blend
- One-way from Blend
One-way integrations send consumer data to Blend in order to start an application. The CRM does not receive updates as the consumer moves through stages of the transaction or if the consumer's data is updated in Blend.
One-way integrations are easier to set-up, but less featureful for customers.
Two-way integrations both post consumer data into Blend AND receive updates on that consumer if their information is updated or as they move through the transaction. This maintains a consistent picture of the consumer in both systems.
One-way CRM integrations are usually initiated from the CRM's side, either by allowing users to manually trigger sending a consumer's information to Blend, or automatically triggering the integration to Blend based on logic in the CRM (lead moved to active, e.g.). A consumer must be tied to at least 1 application in Blend, which means this process must also create the application the consumer will be attached to.
Follow the steps on the Create a New Home Lending Application page to create an application and add parties and their information to the application.
Once the information has been sent to Blend, the CRM will not get updates about changes to any of this information in Blend.
Two-way CRM integrations still usually start on the CRM's side, with the CRM initiating an application and creating parties in Blend just like the above example.
However, unlike the above, CRM's can get structured updates on when changes occur by subscribing to the appropriate webhook Event Notifications.
In addition to the instructions outlined above, you will also need to subscribe to Blend's Event Notifications to enable two-way data syncing.
Blend's Event Notifications utilize standard webhook architecture. In order to receive Blend Event Notifications, you will have to create an endpoint that can receive and parse the events, and contact Blend in order to get your subscription set up properly.
Once you are receiving Event Notifications on consumer updates, you will need to write logic on the CRM side to decide what to do with those events. Usually you want to update the consumer's information in your system, or update the status of the consumer/lead/opportunity.
In the final system, the process will look like this:
- CRM creates an application and initial application party in Blend
- Consumers use Blend and update some of their information
- CRM gets an event notification that consumers information has been updated
- CRM calls Blend's API to get the information that needs to be updated and makes the changes in it's systems
- Consumers submit their application
- CRM gets an event notification that the application status has been updated
- CRM may call Blend's APIs to get additional information or not
- CRM updates the Lead/Opportunity in it's systems
Identifying Application Source
Make sure to include applicationSource 'type' and 'name' values when you create applications in Blend via a POST home-lending/applications call, this way your Employee teams operating in Blend will be able to use this information to distinguish applications that originated in your CRM or LOS from those they originated in Blend.
For more information, please see the API Schema Reference for POST home-lending/applications.
If you want to allow Lenders or Bankers to seamlessly move between the LOS and Blend, see
Leveraging Lender SSO for Integrations.
Updated almost 4 years ago