Performance improvement
Please see the Performance improvement section.

Do not expect all fields in response
The sample input of requests and the data model page list the complete set of fields that are available for an entity. The fields in the actual response can vary depending on the data available at provider sites.

Expectations and code for new values for enums
All enums tend to grow for business reasons. You are asked not to code based on the fixed set of values provided. We recommend that you code for unexpected values in a way that implementation does not break at any point.
  • Examples of enums—accountType, holdingType, status, additionalStatus.
  • Please refer the data model page to know all the enums.
Occasionally, existing values will be replaced with a new value for better reasons. Yodlee will let customers know about the new and changed values well in advance of a release.

Do not base business logic on message strings
Do not code business logic based on the message strings.
Example: Error Messages - The messages are for information and may be enhanced or fine-tuned for better understanding.

Know and code for different MFA providers
If you are not using Yodlee FastLink, code for the different types of MFA supported by Yodlee
  • Security questions and answers
  • Token ID authentication
  • CAPTCHA image authentication
  • Multistep authentication
Refer to the loginForm entity datamodel for details.

Implement the recommended logic in add/update account flows:
If you are not using Yodlee FastLink, code for the following in the add/update account flows :
Recommendation Benefit
 Construct the login form user experience using all the login form fields provided including the optional fields.  Reduced user confusion while providing credentials; as login field names displayed to them will be same as those in the provider site
Use the maxLength field, if provided in the login form fields. Limits users from inputting credentials less than or exceeding the permitted length on the provider site
Implement the Re-enter Password feature while accepting credentials from users Avoids errors when credentials are entered by users since they will be required to enter same credentials twice
Implement the Show Password field in the login form screen Gives users the option to view the characters they entered passwords and will help them verify whether it is the correct password
Implement  the Edit/Update Credentials option in their application Helps users update their credentials during the add account flow rather than reaggregating them multiple times and avoids creating multiple provider account IDs
Display site-level and login form help text provided in the login form to users Helps users provide the correct set of information for successful aggregation/log in
Do not allow users to copy and paste passwords in to the login form Ensures that a user is not entering additional characters unintentionally and there are no cookie issues
1. Users should select at least one option to enter their credentials when the login form has multiple options.

2. A user should not fill all optional fields.
Ensures that users do not leave a necessary field blank and fills in only truly necessary information.
Display help tips on the widget or application to help your users aggregate accounts successfully. Some recommended tips follow:
  • Your credentials should be entered exactly as required for the site. For example, if you enter 16 digit card number don’t add hyphens or spaces.
  • Verify you are using the correct URL to link your account. There can be more than one.
  • If you are copy pasting password, paste the password into a text editor to make sure there are no unwanted characters.
Ensures that users aggregate their accounts successfully.
Configuring implicit and on demand datasets
Ensure that you have the right set of datasets configured as implicit. Datasets that are demanded (i.e. on demand) during the request also have to be configured.
Please work with our sales and customer service teams during the integration phase to configure the datasets as implicit or on demand.

Know the datasets supported by your provider
The GET-provider/{providerId} API service lets you know what datasets are available for a provider. If you want to explicitly pass datasets, provide only the datasets supported by your provider to PUT/POST- providerAccount API services.

Know the dataset additional status field
The dataset.additionalStatus field in the providerAccount API services response gives detailed information on why the PUT/POST-providerAccount API service call failed. You have to refer to the list of dataset.additionalStatus values in the data model page and design the user experience on your application.