v5.0.0 Upgrade Guide
This upgrade guide reviews all of the breaking changes in version 5.0.0, and how you should update your code if you're looking to move to 5.0.0. For a full list of changes in version 5.0.0, please see the changelog.
Application export / Application exported split
Breaking Changes
Both application exports initiated in Blend and updates of the LOS ID for a loan through the Public API used to trigger an application update event with trigger.type: EXPORTED
. These have been separated into different application update events with distinct trigger types in v5.0.0:
-
Application exports initiated in Blend will emit an application update event with
trigger.type: EXPORT
-
Updates of the LOS ID for a loan through the Public API will emit an application update event with
trigger.type: EXPORTED
How to upgrade
Event subscribers upgrading to v5.0 wishing to preserve original behavior should treat application update events with trigger.type: EXPORT
and trigger.type: EXPORTED
as the same.
/packages
required fields
/packages
required fieldsBreaking Changes
In previous versions, radio group tabs in documents had the required property in each radio item inside of the group. As an example, consider this POST /packages
request body:
{
"type": "INITIAL_LOAN_ESTIMATE",
"foreignPackageId": "123",
"applicationId": "{{applicationId}}",
"envelopes": [
{
"providerType": "ESIGN",
"recipients": [
{
"partyId": "{{borrowerA}}",
"metadata": {
"documents": [
{
"documentId": "{{conditionalDoc}}",
"tabs": [
{
"type": "radioGroup",
"attributes": {
"groupName": "randomRadioGroup",
"radios": [
{
"xPosition": 150,
"yPosition": 150,
"pageNumber": 1,
"required": true
},
{
"xPosition": 160,
"yPosition": 160,
"pageNumber": 1,
"required": true
}
]
}
}
]
}
]
}
}
]
}
]
}
In version 5.0.0, the required property is contained in the attributes object of the radio group, and not in each individual radio item. The example request body above would now look like this:
{
"type": "INITIAL_LOAN_ESTIMATE",
"foreignPackageId": "123",
"applicationId": "{{applicationId}}",
"envelopes": [
{
"providerType": "ESIGN",
"recipients": [
{
"partyId": "{{borrowerA}}",
"metadata": {
"documents": [
{
"documentId": "{{conditionalDoc}}",
"tabs": [
{
"type": "radioGroup",
"attributes": {
"groupName": "randomRadioGroup",
"required": true,
"radios": [
{
"xPosition": 150,
"yPosition": 150,
"pageNumber": 1,
},
{
"xPosition": 160,
"yPosition": 160,
"pageNumber": 1,
}
]
}
}
]
}
]
}
}
]
}
]
}
How to upgrade
For any request body used in calls to POST /packages
, the required
field on all individual radio items should be moved up one level to the attributes
object of that radio group tab. This process would have to be done for both required: true
and required: false
radio group tabs.
Similarly, GET /packages
and GET /packages/{id}
now return radio group tabs with the required
field in the attributes of the radio group instead of in each individual radio item. Be sure to update your GET
response validations, if any, to reflect this change.
Packages (POST
& GET /packages
) WETSIGN
recipients metadata schema
POST
& GET /packages
) WETSIGN
recipients metadata schemaBreaking Changes
In previous versions, the metadata of WETSIGN
recipients contains an array of strings named documentIds
:
{
"metadata": {
"documentIds": ["documentId1", "documentId2"]
}
}
In 5.0.0, the documentIds
field is replaced by an array of objects named documents
. Each object contains a single property, documentId
:
{
"metadata": {
"documents": [
{ "documentId": "documentId1" },
{ "documentId": "documentId2" }
]
}
}
How to upgrade
For POST /packages
: In the WETSIGN
recipient metadata section of the POST
request body, change the documentIds
field name to documents
, and convert each string in documentIds
to an object with the documentId
field set to the old string.
For GET /packages
and GET /packages/{id}
: Expect to receive the documents
field in the response instead of documentIds
. This means renaming any references to documentIds
to documents
, and altering any processing code to look at the documentId
field of each item (which will now be an object), rather than the object itself (previously a string).
Packages (POST
& GET /packages
) ESIGN
recipients metadata schema
POST
& GET /packages
) ESIGN
recipients metadata schemaBreaking Changes
In previous versions, the documents
field of the metadata in ESIGN
recipients accepts both the tabs
and tabExtractionMethod
fields:
{
"metadata": {
"documents": [{
"documentId": "documentId",
"tabs": [],
"tabExtractionMethod": "ENCOMPASS"
// additional fields
}]
}
}
In 5.0.0, the documents
field can contain either tabs
or tabExtractionMethod
, not both:
{
"metadata": {
"documents": [{
"documentId": "documentId",
"tabs": [],
// ^ only contains tabs
}]
}
}
{
"metadata": {
"documents": [{
"documentId": "documentId",
"tabExtractionMethod": "ENCOMPASS",
// ^ only contains tabExtractionMethod
}]
}
}
How to upgrade
For POST /packages
: Only put either tabs
or tabExtractionMethod
field in the documents
field of the ESIGN
recipient metadata in the request body.
For GET /packages
and GET /packages/{id}
: Expect to receive either tabs
or tabExtractionMethod
field in the documents
field of the ESIGN
recipient metadata in the response.
POST /packages
Response
/packages
ResponseBreaking Changes
In the previous version, the response of POST /packages
is an object containing an _id
field:
{
"_id": "packageId"
}
In 5.0.0, the field is renamed to id
:
{
"id": "packageId"
}
How to upgrade
Expect to receive the id
field instead of _id
in the response of POST /packages
endpoint.
Deposit Account Reporting (GET /reporting/deposit-account-application)
Breaking Changes
The response field coapplicantRejected
has been deprecated and replaced with the more accurately titled field coapplicantRejectedViaAan
. The original field always only indicated whether the coapplicant was rejected via an adverse action notice (AAN) in the Identity Verification workflow, and now the title makes that scope limitation clear. Furthermore, the new enhanced field takes a null
value instead of FALSE
if the coapplicant's information has not actually been submitted for IDV.
How to upgrade
Replace all references to the deprecated field name coapplicantRejected
with the new field name coapplicantRejectedViaAan
.
New schema for POST /close/closings/:id/enote
endpoint
POST /close/closings/:id/enote
endpointBreaking Changes
In the previous version, the request body contained a top level property, smartDocTemplateData
, that contained either a fixedLoan
or armLoan
sub-object with fields that were specific to the eOriginal eNote provider, for example:
{
"smartDocTemplateData": {
"fixedLoan": {
// fields required to create an eOriginal eNote
}
}
}
In 5.0.0, a new eNote provider, DocMagic, was added with its own specific fields. The request body was modified to be more generic, allowing API callers to specify docmagic- or eOriginal-specific fields in a a sub-object. smartDocTemplateData
was removed from the top level and fixedLoan | armLoan
was moved up instead:
{
"fixedLoan": {
// fields required to create an eNote, common to both providers
"docmagic": {
// fields specific to the docmagic provider
},
"eOriginal": {
// fields specific to the eOriginal provider
}
}
}
How to upgrade
Reach out to us and we can help migrate you to the new system.
Updated over 1 year ago