April 30, 2016

April 2016 Release Notes
Envestnet | Yodlee

1. New Features and Enhancements Summary

  1. The following are the new services that have been made as part of this release:
    1. Create user-defined categories.
    2. Update user-defined category names and system-defined category names.
    3. Delete user-defined categories.
    4. Get categories with support for high-level and user-defined categories.
    5. New endpoint providerAccounts have been released with the following services:
      1. Enhanced simplified add provider account flow with webhooks support.
      2. Enhanced simplified update and refresh provider account flow with webhooks support.
      3. Get provider account(s) that will return the failed accounts along with the succesful additions too.
      4. Delete provider account(s).
  2. The name of the transaction category list service has been changed from transactionCategoryList to categories. Customer implementations will not be disturbed because the existing support for the old API will still be continued and the old API will be hidden from the swagger documentation.
  3. Following are the enhancements that have been made for the get transactions service:
    1. The type field is added as an input to the get transactions service. This input accepts only the investment transaction types and helps filter investment transactions.
    2. The category field available as an input to the get transactions service has been enhanced to accept the user-defined category name along with the existing system-defined category names; one or the other must be chosen. This input helps filter the transactions by system-defined or user-defined. category.
    3. Category in the response can be system defined or user- defined category.
  4. The categoryName input in the update transaction service can now accept a user-defined category along with the support for existing system categories.
  5. Enhancements have been made in the categorization rules API to create, update, run and delete rules for a user-defined category.
  6. The webhooks feature has been introduced and will be available for the following events of the enhanced add/update provider account process:
    1. User Input Required
    2. Interim Progress
    3. Process Completed.
  7. New fields have been introduced in the following services:
    1. get investment options
    2. get accounts(applicable for 401k accounts only)
  8. The following enhancements have been made for the search provider functionality:
    1. Enhanced search algorithm to provide better and relevant search results.
    2. URLs can be used to search providers.
    3. The results appear in the order of: exact matches, starts with, and contains for the search text provided.
  9. The transactions pagination feature has been enhanced so the next link will not be provided in the header when there are no records available for the next page.
  10. The transaction count API has been enhanced to have all the query parameters that the transaction API supports.

2. New API Details

API Names

Details
GET /{cobrandName}/v1/transactions/categories

Get categories service has been introduced to provide the list of system-defined categories and user-defined categories.
PUT /{cobrandName}/v1/transactions/categories

Create category service API introduced under the transactions endpoint to create the user-defined categories.
POST /{cobrandName}/v1/transactions/categories

Update category service API introduced under the transactions endpoint to rename the master-level, and user-defined categories.
DELETE /{cobrandName}/v1/transactions/categories/{categoryId}

Delete category service API introduced under the transactions endpoint to delete the user-defined categories only.
POST /{cobrandName}/v1/providers/{providerAccountId}

Add provider account is an enhanced simplified version of the existing add account API under providerAccounts end point. This API has support for webhooks notifications.
PUT /{cobrandName}/v1/providers/providerAccounts

Update provider account is an enhanced simplifed version of the existing update account API under providerAccounts end point. This API has support for webhooks notifications.
GET /{cobrandName}/v1/providers/providerAccounts/{providerAccountId}

Get provider account will return the status information of the provider account. This API can also be used to retrieve the credentials for the provider account.
GET /{cobrandName}/v1/providers/providerAccounts

Get provider accounts will return all the provider accounts for the user including the failed ones.
DELETE /{cobrandName}/v1/providers/providerAccounts/{providerAccountId}

Delete provider account introduced under the providerAccounts endpoint to delete the provider account.

 

1.1 Need for ProviderAccounts Endpoint

 

Existing Add/Update/Get Provider Accounts flow(Refresh&Providers Endpoint)

New Add/Update/Get Provider Accounts flow(ProviderAccount Endpoint)

The existing processes add account, update account, and get provider account statuses are available under two end points: refresh and providers

With this new providerAccount end point, add and update accounts, and get provider account information flow has been simplified and the features are offered through three services.

Early adopters provided feedback that the refresh end point needs to be collapsed and should be made available under providers.

providerAccount end point under providers made more sense,

  • As Yodlee do not want to disturb the existing customer implementation.
  • As Entity that is being created, updated and deleted is providerAccount end point.

Webhooks support could not be done efficiently as the features are distributed in five different APIs.

Support for webhooks for add accounts and update accounts related events.

Add account and update account accept the provider account object.

Input fields are enhanced so that login form or credentials field array can be provided as an input for the same.

Note: Provider account object is heavy compared to login or fields array object.

Existing refreshStatus value field have the information about the status and additional information combined in one field.

The status information is optizimized in the new APIs. Three fields’ status, additionalStatus & additionalInfo are added to provide more details about the process information.

No information provided in the API response, if the update flow cannot be triggered for the response.

Detailed information provided in the API response, if the update flow cannot be triggered for the response.

ProviderAccount Id based refresh accounts feature is not available

ProviderAccount Id based refresh accounts is made available

 

1.2 Providers, Refresh vs Webhooks Supported ProviderAccount API Mappings

 

Action

Providers & Refresh Endpoint APIs

ProviderAccount Endpoint APIs
Add Account POST /{cobrandName}/v1/providers/{providerId} POST /{cobrandName}/v1/providers/providerAccount
Update Account w/o Credentials POST /{cobrandName}/v1/refresh PUT /{cobrandName}/v1/providers/providerAccount
Get Credentials GET /{cobrandName}/v1/providers/{providerId} GET /{cobrandName}/v1/providers/providerAccount
Update Account with Credentials PUT /{cobrandName}/v1/providers/{providerAccountId} PUT /{cobrandName}/v1/providers/providerAccount

Get Update Account Status

 GET /{cobrandName}/v1/refresh GET /{cobrandName}/v1/providers/providerAccount

Get Add Account Status

 GET /{cobrandName}/v1/refresh/{providerAccountId} GET /{cobrandName}/v1/providers/providerAccount

Get MFA Information

 GET /{cobrandName}/v1/providers/{providerId}

GET /{cobrandName}/v1/providers/providerAccount

Post MFA Information

 PUT /{cobrandName}/v1/providers/{providerAccountId}

PUT /{cobrandName}/v1/providers/providerAccount
  Note: All the actions are accomplished using six APIs

Note: All the actions can be accomplished using three APIs

 

3. Existing API Enhancement Details

 

Existing
API Names

Enhancement Details

GET /{cobrandName}/v1/transactions

1. type field has been added as a query parameter

2. category field accepts user-defined categories too.

3. category field in the response can be a system-defined or user-defined category.
GET /{cobrandName}/v1/transactions/count

Following are the query parameters added for this API:

  1. container
  2. baseType
  3. merchant
  4. keyword
  5. accountId
  6. fromDate
  7. toDate
  8. category
  9. type
POST /{cobrandName}/v1/transactions/{transactionId}

The category name input field can accept user-defined category names. This enhancement is for updating the transaction with the user-defined category.
POST /{cobrandName}/v1/transactions/categories/rules

 

The value field in the rule JSON parameter can accept the user-defined category id too. This enhancement is for creating a user-defined category rule.
PUT /{cobrandName}/v1/transactions/categories/rules/{ruleId}

 

The value field in the rule JSON parameter can accept the user-defined category id too. This enhancement is for updating a user-defined category rule.
DELETE /{cobrandName}/v1/transactions/categories/rules/{ruleId}

The ruleId to be deleted can be the one created for the user-defined category too.
GET /{cobrandName}/v1/transactions/categories/rules

This service will return the rules created for user-defined categories too.
POST /{cobrandName}/v1/transactions/categories/rules/{ruleId}

ruleId to be run can be the one created for user-defined category too.
GET /{cobrandName}/v1/accounts/investmentPlan/investmentOptions

The following fields are provided in the investment options response:

  1. returnAsOfDate
  2. feesAsOfDate
  3. inceptionDate
  4. inceptionToDateReturn
  5. yearToDateReturn
  6. grossExpenseRatio
  7. netExpenseRatio
  8. grossExpenseAmount
  9. netExpenseAmount
GET /{cobrandName}/v1/accounts/{accountId}

Following fields are provided in the account details response for 401k accounts:

  1. lastEmployeeContributionAmount
  2. lastEmployeeContributionDate

 

4. Bugs Fixed:

  1. Account id was incorrectly provided as a string in the historicalBalances service response. The issue has been fixed, so the account id is returned as an integer.
  2. Money component type attributes were appearing in the response, though the amount was not available in the back end. This issue has been fixed and the money attributes will not come in the response if the amount in the component is null.
  3. Merchant names with double quotes resulted in an invalid JSON response. This issue has been fixed by using a backslash (\) before the quotation marks in the merchant name in the response, e.g., Toys\"R\"Us.