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.
Benefits of Yodlee Core API v1.1 include:
- Simplified and faster integration – only a single FastLink integration is needed for multiple data requests and workflows.
- Performance has been improved so only the requested data is retrieved, e.g., choosing transactions under basic aggregation data.
- Reduced user friction and enhanced 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 on the page. For more information, refer to Yodlee Aggregation API reference v1.1 page. For FastLink, refer to the FastLink 4 Product Guide.
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
- Step 1: Data Conversion
Yodlee performs the container to site data conversion and error code to additional status data conversion. The data migration activity will take 1-2 hours for a user base of <200K users. - Step 2: Dataset Configuration
Yodlee configures the datasets required for a customer based on its use cases.
- Step 1: Data Conversion
- 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.
- Step 1: Data Conversion
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.
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 before the migration is done. Deleting duplicate accounts after migration will lead to refresh issues. - 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
Before allowing an account or providerAccount to be refreshed, it is essential to make the GET /providerAccount API call to get the latest status of the accounts. Ideally, this call is made when the account display page loads to accurately indicate which accounts can or cannot be refreshed and how they can be fixed.
The updateEligibility field, provided in the GET accounts and GET providerAccounts endpoints, can be used to display the refresh or edit credentials options. The updateEligibility field returns the following values:- ALLOW_UPDATE - Indicates that the user can refresh the account and get the latest data from the financial institution. The account refresh process can be triggered via the API or the FastLink refresh account flow.
- ALLOW_UPDATE_WITH_CREDENTIALS - Indicates that the user will have to take some action on FastLink before the accounts can be updated with the latest data. The FastLink edit flow must be invoked in this case.
Only exception is when additionalStatus is INVALID_ADDL_INFO_PROVIDED or ADDL_AUTHENTICATION_REQUIRED. For these two additionalStatus, use the refresh account flow instead of the edit account flow although the updateEligibility value is set to ALLOW_UPDATE_WITH_CREDENTIALS. - DISALLOW_UPDATE - Indicates that the account data is the latest and cannot be refreshed again at this point. In this case, the user should not be allowed to trigger an account refresh. This value is returned mainly after a successfull aggregation, and stays the same for 15 minutes.
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 Aggregation 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 Aggregation 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 4 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 use the Aggregation configuration. |
| 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 use the Verification configuration. |
Note: Customers can also request basic aggregation and verification in one single Configuration.
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 –
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 FastLink 4, 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 4 integration guide. As Yodlee incurs additional costs to retrieve the following information from pages other than the landing page, you will have to configure the dataset attributes in the FastLink configuration 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 attributes are mandatory for your use case, then both attributes have to be explicitly requested.
Note: If the information is available on 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 updating account flows. This eliminates the need to poll 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. Note that Data Extracts can return a lot of data, and hence by default, pagination is available for the transaction entity in this API. In the first response, the API will retrieve 500 transactions along with other data. The response header will provide a link to retrieve the next set of transactions.
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 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 |