Overview

For the complete and simple Changelog see v2.2.0 Changelog

This document is an extension of the above Changelog that gives more context on these changes. It is for users of Blend's APIs to help you understand:

Changes that impact the behavior of the API in this version
New features and functionality that are available to you in v2.2.0

Don't forget that v1.X.X functionality will no longer be supported as of October 31st, 2019. Please see the previous Upgrade Guides for guidance on what you will need to change to make the transition to utilizing v2.0.0 or higher API version:

Announcements

Improved Documentation Website Launched

We've launched a new documentation website including several exciting new features for managing the communication around our APIs:

Design Improvements: Enhanced Navigation, Readability and Search across both the API Schema Reference and the How-To Guides.
Versioned Guides: Blend's How-To Guides are now versioned along with the API. This means you can always find the correct information specific to the version of the API you are using.
Suggested Edits: Find an error in the docs or think something can be clarified? Use the suggested edits feature to easily let us know how we can improve your experience!

Bug Fixes

/Events Routes Version Pinning Issue Resolved

Previously, when using the /events routes, users had to pass "1.0.0" in the api-version header regardless of what overall version of the API they were utilizing. This has been fixed as of v2.2.0 with backwards compatibility.

Passing "1.0.0", "2.0.0", "2.1.0" or "2.2.0" when utilizing the /events routes will all now result in success and result in the same behavior.

In the future, passing different version headers to this endpoint will result in different event schemas being returned if the event schemas have changed between versions.

Additional Benefits of v2.2.0

Loan Assignment Routes

Integrators now have the ability to update who is assigned to a loan after the loan has been created. The GET /loans/id/assignees allows users to get the current set of assignees on the loan. Whereas PATCH and PUT allow for the assignees to be updated.

These endpoints are useful for reassigning loans or adding assignees based on programmatic triggers, and making sure unassigned loans don't get lost in the shuffle.

GET Lenders Route Paginated. Can now return all Lender Users

The GET Lenders Route now uses cursors to paginate its results, which allows it to return a much higher number of responses. Additionally, the "ids" query parameter that allows searching for a single Lender or array of Lenders, is now optional. This is helpful when checking if a Lender exists in Blend before creating them a Blend User or trying to assign that User to a Loan, and reduces the amount of processing integrators have to do on their side to accomplish these tasks.

For more information about how Cursors work in Blends API see our API Technical Standards documentation on Pagination (Cursors).

LOS Milestone Behavior Changes and New Routes

As their default behavior, calls to POST /external/loans/los-milestones will now only accept LOS milestones that have been added to your customer configuration and will no longer allow loans to transition to previous milestones (e.g. APPROVED → UNDERWRITING).

If you still need to transition to an LOS milestone that does not satisfy the above conditions, set override: true in the request body.

New routes were also added to provide non-bulk operations for both reading and writing milestones on one loan at a time:

GET /external/loans/:id/los-milestones will return the current LOS milestone of the desired loan
PATCH /external/loans/:id/los-milestones will update the LOS milestone of the desired loan. This endpoint follows the same constraints as POST /external/loans/los-milestones does, which are described above.

Additional Borrower Information Available via the API

Calls to GET /loans/:id/borrowers will now return:

Date of Birth (as a UTC timestamp string in ISO format)
Social Security Number (SSN)
Borrower Credit Summary
These additions ease the pain of parsing the MISMO to acquire this critical Borrower information.

POST/PATCH Borrower eConsent from external endpoint

Calls to POST /borrowers and PATCH /borrowers/:id can now include the eConsent object for the Borrower. This object will also be returned in the response body if the Create or Update action is successful.

The eConsent field is optional, so if the caller does not need to update eConsent, this object can be left out.

The eConsent object matches the format of the current eConsent object returned on a GET call to these routes. However, POST and PATCH actions will only accept "Accepted" or "Declined" eConsent types. "Pending" is an option that can be returned by the GET route, but will result in an error if passed to POST or PATCH.

econsent: {

    status: "Accepted" or "Declined",

    date: ISO String or null

    ip: string (e.g. "10.123.456.78") or null

}

Third Party Recipient Management to enable Disclosures

New routes were added to support the addition of Third-Party Disclosures Recipients, such as non-borrowing owners, for Disclosure delivery via Blend.

POST /parties allows the addition of "Parties", who need to be associated with a loan, but are not Borrowers. For example, "TITLE_HOLDER" refers to a non-borrowing owner. These Parties also need "verificationData", which proves their identity when they go to open Disclosures packages issued to them via Blend.
PATCH /parties allows the modification of already added Parties.
DEL /parties allows the deletion of already added Parties.
GET /loans/:id/parties allows a user to view the set of Parties currently associated with a loan.

Third Party Recipient Disclosure Delivery

Calls to POST /disclosures-packages can now include signature tabs (with the existing TabSchema) for Third-Party Recipients on the Document Object. The same schema format will be supported as is today for a Borrower's signature tabs.

Describe Events Route

This new route allows API integrators to dynamically grab the list of the events to which they are subscribed, or alternatively, to return the schemas of all those events as well. This is helpful during the build phase of event-driven integrations, but also allows integrators to begin dynamically responding to many standardized event schemas rather than hardcoding their schema parsing of each individual event.

Reporting API Enhancements

The Blend Reporting API gives integrators programmatic access to end-of-day reporting data on activity within Blend between internal and external users on the platform. The API allows integrators to connect this data store in their preferred warehousing destination but also can serve data directly to existing BI or Analytics tools already leveraged by the organization.

This API will allow the organization to better measure Blend's performance, serving as an alternative to Blend's deprecated Daily Analytics Package, and is a single, easy-to-use, scalable set of endpoints to obtain the data relevant to the loans in Blend's platform.
In v2.2.0, a new endpoint was added called /lender-stats that allows a user to retrieve high-level statistics around each Blend user. Additionally, a number of useful fields were added to the GET /loans and GET /borrowers.