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.