Upgrade Guide – Legacy (REST/SOAP) to v1.1

Here we explain the steps that are involved in migrating or upgrading to the fully RESTful Yodlee Core API v1.1.
This document also explains the new terminologies, new features, and deprecated features of legacy requests, alternative steps for critical flows that the Yodlee Core API v1.1 recommends.

Introducing Yodlee Core API v1.1

Yodlee Core API v1.1 is a modern RESTful API that offers a simple, intuitive, and secure way for developers to access the Envestnet | Yodlee financial data platform. Our core value is not just to be the leader in providing financial data but also to deliver a world-class developer experience.
The Envestnet | Yodlee financial data platform, through  RESTful requests, provides developers with access to over 17,000+ data sources for financial data, including bank direct deposit accounts (DDAs), wealth, credit card, loans, insurance, small business, and more. Integration and seamless access to data enable developers that use our platform the ability to deliver rich user experiences.

Envestnet | Yodlee has released two versions of RESTful Yodlee core APIs:

  • Version 1.0 - released in Dec 2015
  • Version 1.1 - released in Dec 2017

Use FastLink for Linking Accounts

If you are a customer who has already implemented Yodlee legacy APIs for building the link account experience, Yodlee strongly recommends you to move to FastLink due to the following reasons:

  • FastLink has already done the heavy lifting of implementing APIs for account addition and editing credentials. This helps you integrate faster and concentrate more on your business flows.
  • With FastLink, you can go faster to market.
  • Yodlee has accelerated many experiments to improve the user experience in FastLink which helps you bring better conversion rates.
  • FastLink user experience enhancements, reduce user errors to a great extent.
  • With the accelerated Open Banking transformation in the US market, there will be frequent changes in the APIs to adopt to the FIs open banking flows; this costs a lot of development time from your side and delays the time to market.

Upgrade Steps

Pre-upgrade

Change the API implementations as per the upgrade guidelines provided in the page. For more information, refer to Yodlee API v1.1 reference page. For FastLink, refer to the FastLink 3.0 Product Guide and the Getting Started with FastLink pages.

Upgrade Process

Yodlee recommends upgrading using the stage environment before moving to the production environment. Downtime is required for data migration activities.

  • Container-based Customer Migration
  • Site-based Customer Migration
    • Step 1: Data Conversion
      Yodlee performs the error code to additional status data conversion. The data conversion activity will take 1 hour for a user base of <200K users.
    • Step 2: Dataset Configuration
      Yodlee configures the datasets required for a customer based on their use cases.

Post-upgrade

  • Yodlee will restart the customer server so the configurations can take effect. The downtime required varies based on the number of users, number of accounts, and the number of instances that are available to the customer.
  • Once Yodlee notifies you, you can start invoking FastLink widget.
  • To ensure that the calls are a success, test the following scenarios:
    • Add accounts for MFA and non-MFA accounts.
    • Edit credentials for MFA and non-MFA accounts.
    • Instant refresh for MFA and non-MFA accounts.
    • Replicate the incorrect credentials and incorrect security answer for a Q&A site error scenarios, and rectify the same.
    • Monitor the cache refreshes.

Dataset Configuration

A dataset is the classification of data that Yodlee retrieves from data providers. To know more about the datasets that Yodlee supports, please refer to Working with Datasets. Depending on the data that you have been retrieving using v1.0 API and the new data that you need, datasets and the containers have to be configured in the Yodlee back end.

Contact the Sales or the Yodlee Client Services team to configure the datasets and containers you require on-demand, datasets that have to be retrieved by default, and the auto-refreshable datasets.

Default Dataset Configuration

For your product's primary workflow, if only a fixed set of data is required, it should be configured as implicit or default datasets. Once configured, you do not have to pass the dataset every time you link an account or update an account.

If your product requires two different sets of data, you will have to decide which one has to be configured as default. For example, in the aggregation flow, even if no dataset names are passed, the default datasets will be considered. But in the account verification flow, you need to explicitly pass datasetName as ACCT_PROFILE to retrieve the data pertaining to the dataset.

Important Notes You Should Know

  • Reconciliation
    Yodlee recommends that you use data extracts if you are a customer who retrieves and stores data in the local database by performing reconciliation using Yodlee APIs. We notify you whenever there are changes to data. For more information, refer to the Data Extracts page.
  • Duplicate Accounts
    If you are a container-based customer who has not implemented the edit credentials flow or has allowed multiple additions of account with the same credentials, you may have multiple items accounts for the same site for the same set of credentials.
    In such a case, after data migration, you may see duplicate accounts under one providerAccount. You will have to instruct your user to delete the duplicate accounts.
  • Error Code vs Status Mapping
    Previously, to detect if the account aggregation process succeeded you checked statusCode or errorCode at the mem item or the mem site account-level. In Yodlee Core API v1.1 to know the data retrieval status, you have to check the dataset.additionalStatus at the account-level.
  • Data Not Available Status vs 414/422 Status Codes
    The 414 or 422 codes at the mem item-level in legacy APIs indicate the account is not available at the site. In Yodlee Core API v1.1, the DATA_NOT_AVAILABLE additional status indicates the same; this is not an error as it is a site or data unavailability issue.
  • Fields That Help Display the Refresh and Edit Credentials Options
    The account.updateEligibility field provided in the GET accounts endpoint can be used to display the refresh or edit credentials options.
    • The refresh or retrieve the latest updates option can be displayed to your users when the value is account.updateEligibility = ALLOW_UPDATE.
    • The edit credentials option can be displayed when the value is account.updateEligibility = ALLOW_UPDATE_WITH_CREDENTIALS.
    Note: When the refresh is not allowed due to incorrect or expired credentials, the edit credential option should be provided in the response.

Container Differences

Containers that are mapped and merged from Legacy API to Yodlee Core API v1.1 follows:

  • Container Mapping
    Legacy API Container Yodlee Core API v1.1 Container
    Bank bank
    credits creditCard
    insurance insurance
    Stocks investment
    Loans loan
    Miles reward
    RealEstate realEstate
  • Container Merged
    Legacy API Container Yodlee Core API v1.1 Container
    mortgage loan
  • Deprecated Containers
    Yodlee has stopped support for the following containers:
    • bills
    • minutes
    • telephone
    • utilities
    • cable_satellite
    • isp

  • Deprecated Manual Containers
    Manual containers rewards and paymentServices in legacy (REST/SOAP) APIs have been deprecated and are no longer supported in Yodlee Core API v1.1.

Note: Any container that is not listed here is not yet supported by Yodlee Core API v1.1.

Field Name Changes

Most of the input and response parameters are self-explanatory. The terms that you should be aware of while upgrading to Yodlee Core API v1.1 follows:

Legacy API Field Names Yodlee Core API v1.1 Field Names
memSiteAccount providerAccount
memSiteAccId providerAccountId
Site provider
itemAccountId accountId
itemAccounts accounts

Data Access Hierarchy

Data Migration

Data migration activities that are a prerequisite before upgrading to Yodlee Core API v1.1 follows:

  • Migrate Container to Site-based Aggregation –
    Yodlee introduced the site-based account linking concept in 2013. The consumer provides the site that he or she would like to link and Yodlee links all the accounts the consumer has at that site across all containers. The site-based account linking concept replaced the container-based account linking where the consumer had to explicitly add the same site multiple times until all accounts across all containers are added. Customers who have implemented site-based aggregation can skip this data migration step.
    If the customer has implemented container-based aggregation, this data migration step is a prerequisite to invoking the RESTful Yodlee API services. Yodlee's team will engage in the data migration process. As part of the migration process, the user accounts are consolidated based on the credentials that were used to add the account. The consolidation is done by creating a new record named memSiteAcc or providerAccount. All user accounts that have the same credentials are associated with the single memSiteAccId or providerAccountId.
    The account deduplication feature is not available for container-based aggregation. In instances where the user adds the same accounts multiple times, the Yodlee system creates multiple items for the same account.
    Please note, when a user repeatedly initiates the account addition process for the same container, the Yodlee system creates duplicate accounts under the same memSiteAcc or providerAccount.
    Customers migrating to Yodlee Core API v1.1 should prompt their end-users to retain all relevant accounts and discard all duplicate accounts. Contact the Yodlee Client Services team for more information or assistance.

  • Migrate Status or Error Code –
    Yodlee legacy APIs have error codes and a status field to indicate the progress and the state of the add/update account process; multiple error codes are available in the system for similar errors.
    Enhancements in Yodlee Core API v1.1 provide meaningful status at the provider account and account level during the add/update account process. Hence, the accounts that were added using SOAP APIs have to undergo the data migration process, which will help to provide consistent API responses for the already added provider account and accounts. Yodlee's team will be involved in the data migration process.

Deprecated Fields

Customers have to change their implementation if the deprecated fields are used. Contact the Yodlee Client Services team for guidance on an alternative implementation.
Support for the following fields is stopped in the Yodlee Core API v1.1:

Field Names Reason Alternative Recommendations for Critical Flows
ItemId This field is relevant only for container-based aggregation. As Yodlee has moved from container-based aggregation to site-based aggregation there is no value in exposing the item field. To know account/site level status during add/update:
The status of accounts will be available at the account level. The get accounts service should be used to pull the account data.
The status at provider/site level can be known from get provider account detail service data.
To trigger update(refresh) account flow:
Retrieving up-to-date information of aggregated accounts can be achieved using the Update provider account service.
contentServiceId This field is relevant only for the container-based aggregation model. In the RESTful Yodlee API, as only the site based aggregation is supported, this field is killed. providerId indicates a unique identifier for the site.
To get all supported sites:
Get all providers service should be used to retrieve the supported sites or search for sites.
To get the loginform of a site:
Get provider detail service should be used to retrieve the login form of a site.
errorCode This field is used to convey the status of aggregation. 0 indicates success or failure at the container level. Non-zero code indicates the occurrence of error. To know account/site level status during add/update:
The error at accounts level can be known from dataset.additionalDataset field under accounts entity. Get accounts service should be used to pull the error information.
The error at provider account level can be known from status field under provider accounts entity. Get provider account detail service should be used to pull the error information.

Deprecated APIs

The following features from legacy have been deprecated in the Yodlee Core API v1.1:

  • Stopping refreshes offered through POST /stopRefresh service
  • Linking mortgage account to real estate account through APIs
  • Suggested sites

Legacy API vs Yodlee Core API v1.1

The differences between the API calls for each of Yodlee's platform capabilities are highlighted in the section.

Authentication

  • SAML-based Authentication - We do not recommend invoking Yodlee APIs v1.1 using SAML-based authentication. If you are currently using SAML-based authentication, you can continue using SAML only to access FinApps. To access Yodlee APIs v1.1, refer to the authentication approach on the API Reference page. For any other details, contact the Yodlee Client Services team.
  • User and Cobrand login-based Authentication - This authentication method is deprecated for Yodlee APIs v1.1. To access Yodlee APIs v1.1, refer to the authentication approach on the API Reference page. For any other details, contact the Yodlee Client Services team.

Linking or Update Accounts

In Yodlee legacy API, the following were the two types of requests used for aggregating data from provider sites:

  • Aggregation requests – Retrieves accounts, statements, holdings, and transactions.
  • Instant Account Verification (IAV) requests – Retrieves full account number, routing number, and holder details.

In the latest platform, you can retrieve both aggregation and verification data in one single FastLink flow. For more details, refer to the FastLink integration guide.

Legacy API Service Yodlee Core API v1.1 Service
Aggregation requests retrieve: accounts, transactions, holdings, statements If a customer needs accounts, transactions, holdings or statements, the customer should request BASIC_AGG_DATA dataset.
IAV requests retrieve basic account information, full account number, holding name, and routing number. If a customer needs the full account number, holding name and routing number, the customer should request ACCOUNT_PROFILE dataset.

Note: Customers can also request basic aggregation data and account profile in one request.

Learning the status of Link, Edit Credentials, and Refreshing Account Implementation Differences

In the legacy API requests, the errorCode and the status field at the mem site account level are used to display a success or an error message to the user. In Yodlee Core API v1.1, the following two fields that are returned in the GET providerAccounts APIs should be used to learn the different provider accounts statuses:

  • providerAccount.status
  • providerAccount.dataset.additionalStatus
Scenario Legacy API Implementation Info Yodlee Core API v1.1
All accounts are aggregated successfully memsiteAccount.status = REFRESH_COMPLETED
memsiteAccount.errorCode = 0
providerAccount.status = SUCCESS
One or more accounts are successfully aggregated and the remainder failed memsiteAccount.status = REFRESH_COMPLETED
errorCode at item level indicates the reason for the error
providerAccount.status = PARTIAL_SUCCESS
dataset.additionalStatus field in the account and provider account indicates the reason for the error
All accounts failed memsiteAccount.status = REFRESH_COMPLETED
errorCode at item or mem site account level indicates the reason for the error.
providerAccount.status = FAILED
dataset.additionalStatus field in the account and provider account indicates the reason for the error. For example, INCORRECT_CREDENTIALS, UNEXPECTED_SITE_ERROR
Account summary retrieved Not Applicable dataset.additionalStatus = ACCT_SUMMARY_RECEIVED

Please refer to the different additionalStatus values that are provided at the account level and provider account level. Use them for the user experience that you want to offer.

Legacy to Yodlee Core API v1.1 Mappings

  • Core Legacy API to Yodlee Core API v1.1 Mapping
    Legacy API Service Yodlee Core API v1.1
    Method URL Method URL
    GET /account/summary/all GET accounts
    POST /ItemAccountManagement/activateItemAccount PUT accounts/{accountId}
    POST /authenticate/coblogin POST cobrand/login
    (Recommended only for SAML-based authentication)
    POST /TransactionCategorizationService/categorizeTransactions PUT transactions/{transactionId}
    POST /TransactionSearchService/clearUserTransactions N/A  
    POST /ItemAccountManagement/deactivateItemAccount PUT accounts/{accountId}
    POST /TransactionSearchService/executeUserSearchRequest GET transactions
    POST /DataService/getItemSummariesWithoutItemData GET accounts
    transactions
    statements
    holdings
    POST /TransactionCategorizationService/getTransactionCategoryTypes GET transactions/categories
    POST /TransactionSearchService/getUserTransactions GET transactions
    POST /TransactionCategorizationService/getUserTransactionCategories GET transactions/categories
    POST /Login/getUserInfo GET user
    POST /authenticate/login POST user/SAMLLogin
    (The login API is not required for non SAML-based authentication)
    POST /Login/logout POST user/logout
    POST /UserRegistration/register3 POST user/register
    POST /UserRegistration/unregister DELETE user/unregister
    POST /UserRegistration/updateEmail PUT user
    POST /Login/validateUser N/A  
    POST /TransactionCategorizationService/manageUserCategories POST transactions/categories
    PUT transactions/categories

  • Container-based Legacy API to Yodlee Core API v1.1 Mapping
    Container based Legacy API Yodlee Core API v1.1
    Method URL Method URL
    POST /getItemSummaryForItem1 GET accounts/{accountId}
    POST /getAllContentServices GET providers
    POST /getContentServicesByContainerType2 N/A  
    POST /getRefreshInfo1 GET providerAccounts/{providerAccountId}
    POST /isItemRefreshing N/A  
    POST /removeItem DELETE providerAccounts/{providerAccountId}
    POST /removeItemAccount DELETE accounts/{accountId}

  • Site-based Service Legacy API to Yodlee Core API v1.1 Mapping
    Site-based Service Legacy API Yodlee Core API v1.1
    Method URL Method URL
    POST /SiteAccountManagement/getAllSiteAccounts GET providerAccounts
    POST /SiteTraversal/getAllSites GET providers
    POST /DataService/getItemSummariesForSite GET providerAccounts
    accounts
    POST /SiteTraversal/getPopularSites GET providers?priority=popular
    POST /SiteAccountManagement/getSiteAccounts GET providerAccounts
    POST /Refresh/getSiteRefreshInfo GET providerAccounts/{providerAccountId}
    POST /SiteAccountManagement/removeSiteAccount DELETE providerAccounts/{providerAccountId}
    POST /SiteTraversal/searchSite GET providers?name="searchText"

Please refer to the different additionalStatus values that are provided at the account level and provider account level. Use them as needed to offer the user experience that you want.

Error Code to Dataset Additional Status Mappings

Yodlee Core API v1.1 no longer returns an error code. The error status is now provided in the additionalStatus field. The common errors and their causes in the Yodlee Core API v1.1 along with the next action to be performed follow:

Error Code Additional Status Scenario Next Action
407 ACCOUNT_LOCKED The account is locked at the provider site. The user has exceeded the maximum number of incorrect login attempts resulting in locking the account. Instruct the user to visit the provider site and take necessary actions to unlock the account.
518, 519, 520, 522, 573 ADDL_AUTHENTICATION_REQUIRED Additional MFA information is needed at the provider site or to download document additional verification is required. Instruct the user to provide the required additional MFA information or verification.
507 BETA_SITE_DEV_IN_PROGRESS The site for which the data is requested is in the development or beta stage. Instruct the user to try again later or disable the beta sites.
410, 420, 526 CREDENTIALS_UPDATE_NEEDED Unable to log in to the provider site due to outdated credentials. The site may be prompting the user to change or verify the credentials. Instruct the user to visit the provider site and perform the required actions, and invoke the edit account flow to update the credentials in the Yodlee system.
402, 551 INCORRECT_CREDENTIALS Unable to log in to the provider site due to incorrect credentials. The credentials that the user has provided are incorrect. Instruct the user to provide the correct credentials by invoking the edit account flow.
414, 422, 570 DATA_NOT_AVAILABLE The requested data or document is not available at the provider site. Instruct the user to check with the respective data provider or provider site.
509, 523, 524 INVALID_ADDL_INFO_PROVIDED The user has provided incorrect MFA information or the MFA information provided has expired. Instruct the user to provide the correct MFA information.
508, 525, 553, 554, 555 REQUEST_TIME_OUT The request has timed-out for technical reasons. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
426 SITE_BLOCKING_ERROR The Yodlee IP is blocked by the provider site. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
401, 412, 418, 423, 425, 431, 432, 556, 558, 571 UNEXPECTED_SITE_ERROR An error indicating an issue at the provider site, such as the site is down for maintenance. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
411, 417, 421, 430, 505 SITE_NOT_SUPPORTED Indicates that the site does not support the requested data or support is not available to complete the requested action. For example, the site is not available, document download not supported at the site, etc. Inform the user about the latest availability status.
575 DATASET_NOT_SUPPORTED The requested datasets are not supported. Either get the dataset/attribute enabled or remove the dataset/attribute from the input.
409, 424 SITE_UNAVAILABLE The provider site is unavailable. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
400, 403, 404, 408, 413, 419, 517, 552, 557, 559, 561, 572, 576, 577, 578, 579, 601, 708, 709 TECH_ERROR Indicates there is a technical error. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
406, 427, 428, 429, 521, 560 USER_ACTION_NEEDED_AT_SITE The errors that require users to take action at the provider site, for example, accept T&C, etc Instruct the user to visit the provider site and perform the necessary action.
415, 416 SITE_SESSION_INVALIDATED Indicates if multiple sessions or a session is terminated by the provider site. Instruct the user to try again later.
574 ENROLLMENT_REQUIRED_FOR_DATASET The dataset cannot be retrieved as the user has not enrolled for it. Instruct the user to enroll for the dataset and then request it.
504 DATA_RETRIEVAL_FAILED Failed to retrieve the data due to unexpected issues. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
811 PARTIAL_DATA_RETRIEVED Partial data is retrieved for the dataset. Instruct the user to try again if the mandatory data is missing. If the request fails repeatedly, report the issue to the Yodlee Client Services team.
506 NEW_AUTHENTICATION_REQUIRED The site requires re-authentication. Instruct the user to re-authenticate by invoking the edit account flow.
510 PROPERTY_VALUE_NOT_AVAILABLE Either the provider site cannot find the property value or the address provided by the user is incorrect. Instruct the user to provide the correct address or add the real estate account manually.
801, 802 Not applicable The 801 and 802 codes are not mapped to any additional status as they are not error codes. They indicate the in-progress state of the add or update account process that is also indicated by providerAccount.status=IN_PROGRESS. NA
Any other error code DATA_RETRIEVAL_FAILED Failed to retrieve the data due to unexpected issues. Instruct the user to try again later. If the request fails repeatedly, report the issue to the Yodlee Client Services team.

For more information about the legacy error codes and their semantics in legacy endpoints, please refer to the Provider Accounts Resource page.

Account Type Mapping

Due to low data-population rates the following accountType in the legacy API implementation will be provided as OTHER in the Yodlee API account.accountType attribute:

Container Account Type ID Account Type Value
bank 9 401k
bank 16 charge
bank 73 CMA
bank 77 accountsPayable
bank 78 accountsReceivable
bank 79 association
bank 80 cash
bank 81 costOfGoodsSold
bank 107 commuter
loan 2 loan
creditCard 22 card
creditCard 70 prepaid

If you have implemented both legacy and Yodlee API, ensure that the legacy API implementation is using the above mapping to display the account types in your application. The consistency of data displayed in the application is assured irrespective of the legacy or Yodlee API implementation.

I18N & Localization

Currency Conversion
Amounts/Money attributes in requests like accounts, transactions, holdings, etc., are not converted and are given as they are retrieved from the provider site or provided by the user.
Summary amounts in the requests under the derived endpoint are converted to the user’s preferred currency using currency conversion rates.
If the user has no preferred currency set, the summary amounts are converted to the customer’s preferred currency.

Localization
Localization is performed for the following attributes:

  • Transaction Category Names(Master Level Category).
  • Provider Attributes – name, URLs, etc.
    • If the site is supporting the locale that is derived using the locale preference, the site attributes will be provided in that locale.
    • If the site is not supporting the locale that is derived using the locale preference, the site attributes will be provided in the site’s primary locale

The locale to be used is derived using the following order:

  • User login locale
  • User register locale
  • Cobrand login locale
  • Cobrand default locale

Handling Newly Introduced Features

Account Deduplication

The Yodlee account deduplication feature ensures that no duplicate accounts are created in the system when the user repeatedly adds an account that was already added. If the user-provided credentials match a providerAccount’s credentials that already exist in the Yodlee platform, then the existing accounts will be updated.
If not, a new providerAccount is created in the Yodlee platform and it is mapped to the existing set of accounts; accounts are always mapped to the primary providerAccount. The other providerAccounts are provided in the associatedProviderAccountId attribute of the GET accounts API response. Contact the Yodlee Client Services team for more information about the account deduplication feature.

Re-adding Accounts

Re-adding accounts with the same credentials in Yodlee FastLink application should be encouraged only to retrieve deleted accounts. You should always encourage the users to edit credentials through FastLink if the existing providerAccount gives a credential error. Re-adding a new account with the latest credentials will create multiple providerAccounts in the system.

Dataset Requesting Capabilities

In the FastLink and above versions, Yodlee has introduced flexibility to retrieve the preferred combination of enabled data attributes that are specifically required for your business flow through FastLink. To know more, refer to the FastLink integration guide. As Yodlee incurs additional costs to retrieve the following information from pages other than the landing page, you will have to subscribe for the dataset attributes if they are critical for your business flow:

  • Interest Details – The dataset attribute provides details of the interest rate for student loan accounts under the loan container.
  • Payment Details – The dataset attribute consists of loan payment-related details such as payoff amount, outstanding balance, etc. If both the attributes are mandatory for your use case then both attributes have to be explicitly requested.

Note: If the information is available in the landing page, Yodlee will continue to return the same to you, even if you have not subscribed to the datasets or attributes.

REFRESH Webhooks Notifications

Unlike legacy requests, the RESTful Yodlee core API has webhooks support to indicate to customers the progress of add account, edit account, and update account flows. This eliminates the need of polling the requests at frequent intervals. Refer to the Yodlee API v1.1- Webhooks to learn more about webhooks and the implementation details.

Data Extracts Implementation

If customers are using the legacy Yodlee core API and implemented synchronized data extracts, your implementation has to be replaced with the RESTful Yodlee core API. Refer to the data extracts page for more information and implementation details.
We also have built the data extracts feature with webhooks notification capability.

Closed Accounts

With the introduction of Yodlee Core API v1.1, Yodlee supports the ability to identify an account as a closed account. The status field of the account entity reflects the state.
Developers can ask their users to confirm whether the account is closed when the status is “To be closed”. On receiving user confirmation, POST accounts/{accountId} API has to be invoked to update the account status as closed.

Larger Transaction History

Yodlee provides up to 365 days of a consumer's transaction data when adding an account when the data is available at the financial institution's site. As fetching all the transaction data takes time, Yodlee has enhanced its platform capability in which one large response is broken into multiple small responses whenever required; this is a Yodlee internal process.

Note: When the progressive refresh feature is enabled, it helps bring 365 days of data during the add account process. The already added accounts will not have an impact and will continue to have the same transaction data that has already been gathered.

New Data Availability

Following are the new data aggregation capabilities that are available with the Yodlee Core API v1.1:

 

  • Documents – Yodlee provides access to end-users' financial documents that are generally accessible from financial institution sites such as PDF documents like tax documents, monthly statements, etc.
  • User profile information – Data related to the person who is logging in to the site and may not always be the actual owner of the accounts. This information will be site-specific and directly linked to the account.
  • Joint account holder profile information – For joint accounts, the names of individual account owners will be returned (if they are displayed on the site).
  • Payment Profile – The payment profile attribute (i.e., available for the student loan account under the loan container) provides details of the payment address of the lender or the loan servicer to which the monthly payment or the payoff amount should be routed to.

Flexibility to Configure Auto-refresh

In legacy APIs, auto-refresh was either turned ON or OFF for a customer and no flexibility was available. Yodlee Core API v1.1 offers the customer the option to turn cache-refreshes ON or OFF at the provider account-level.

Sample URL Formats

Legacy API URL Format Yodlee Core API v1.1 URL Format
https ://usyirestmaster.yodleeinteractive.com/services/srest
/cobrandName/v1.0/jsonsdk/DataService/getItemSummariesForSite
https ://usyirestmaster.api.yodlee.com/ysl/accounts

Links of Interest