HomeGuidesAPI ReferenceChangelogDiscussions
GuidesAPI ReferenceDiscussions

## Overview

For the complete and simple Changelog see the [v2.1.0 Changlog](🔗)

This document is an extension of the Changelog to give more context. It is for users of Blend's APIs to help you understand:

  • Steps you will need to take over the next year to upgrade to v2.1.0 before the v1.X functionality is no longer supported in October 2019

  • New features and functionality that are available to you in v2.1.0

## Upcoming Breaking Changes

_Who needs to care?:_ Any partner or customer integrating directly with Blend's APIs, BONs/Event Notifications or the Reporting API. Customers that only utilize Blend-managed integrations (e.g. LOSes) will not need to worry about this.

_What's going on:_

Blend has extended the authentication credential improvements included as part of the 2.0 release, including moving from basic auth to using API Tokens. If you got Blend API credentials before November 2018 for any of the following:

  • Blend's API endpoints

  • The Reporting API

  • BONS or Event Notifications We now recommend you request new credentials and replace the old ones in order to take advantage of the additional security and usability benefits:

  • New credentials can be used across all public Blend APIs, which means you only need one credential now to access everything listed at api.blend.com including event notifications and the reporting APIs. 

    • If you would still like to have multiple credentials with more tightly scoped access you can specially request the number of credentials and types of scopes you would like

    • We still recommend moving to the new credentials in order to get the additional security benefits of the new tokens, even if you keep the separation of scopes.

  • New credentials are translated to a higher security format within Blend

  • Credentials are now in an easy to use and more secure Token format 

## What You Need to Do

## How to Upgrade your API Credentials

_Note:_ Blend-managed Integrations (E.g. with LOSes) utilize a separate authentication strategy and their upgrade will be handled separately. No need to worry about these credentials right now – just anywhere that you are directly integrating with Blend's APIs.

  1. Email [[email protected]](🔗) and request new credentials for your Beta or Pre-Prod Blend instance. 

  2. Roll your Beta or Pre-Prod credentials for the API, BONS/Event Notifications, and the Reporting API by:

    1. Replacing old credentials with the new credentials

    2. Using the bearer Auth header instead of the basic Auth header in all API calls

  3. Confirm that you've successfully made the change in Beta and have the appropriate scopes, etc.

  4. Request new credentials for your Production Blend instance

    1. Your old credentials will still continue to work as you make the transition. Old credentials will be removed in October 2019 as part of the v3.0.0 release.

  5. Roll your Production API credentials 

    1. Confirm you are using the new credentials and the bearer auth header for all calls. You can work with your Blend Account team to confirm this. 

## Additional New Benefits of v2.1.0

## New Disclosures Functionality

The POST and PATCH /disclosures-packages endpoints support new fields related to documents. These fields offer enhanced support for various types of Docusign tabs to be added to a document for a borrower or LO to fill out, as well as conditional tabs. In particular, the `TabSchema` now supports `initialHereTabs`, `dateTabs`, and `noteTabs`, and all tabs support Docusign's "conditionalParentLabel" and "conditionalParentValue" fields which allow Docusign tabs to depend on each other.

The POST and PATCH /disclosures-packages endpoints also added `docDeliveryType` to the `DisclosuresPackageDocumentSchema`. docDeliveryType is a string to be populated with one of "wet-sign", "view-only", "embedded-fields", and "esign". This field will eventually replace the `isWetsign` flag that is currently supported on these endpoints in the API, and offers additional information Blend can use to figure out how to send the borrower the document. In particular, "embedded-fields" is used in cases where the signature tabs will not be sent via `TabSchema`, but are metadata in the PDF of the document, and "view-only" will be used for documents that only need to be delivered, but not signed.

## Increased Flexibility for Blend Events

What was previously the `borrower` object in Blend events is now the `parties` object. This allows events to also represent third-parties associated with events, like non-signing recipients for disclosures packages. Moving to the paradigm of parties means that events will be able to handle more flexible use cases in the future without another significant change. Note that Events versions do not update automatically, so you will not see this change unless you request an update to your event subscription from [[email protected].](🔗) 

## Other New Features

### Improved Documents Metadata

The addition of `associatedFields` and `showAssociateFields` to the Documents endpoints enables lenders to get enhanced metadata on documents they receive from Blend. Specifically, for Docusign documents that have time units and employer name present in the document title, they can receive both as additional pieces of metadata to automated processing.

### Expanded Borrower Information

The addition of `phoneNumber` to the `borrowerSchema` enables phone follow-ups workflows for drop-off or post-submit borrowers from Blend.