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

Breaking 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

Breaking 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

Breaking 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

Breaking 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

Breaking 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.