Yodlee Core APIs

OpenAPI apis-guru financial

This file describes the Yodlee Platform APIs using the swagger notation. You can use this swagger file to generate client side SDKs to the Yodlee Platform APIs for many different programming languages. Yodlee supports the Java SDK and it is available . You can generate a client SDK for Python, Java, JavaScript, PHP or other languages according to your development needs. For more details about the APIs, refer to .

Homepage: https://api.apis.guru/v2/specs/yodlee.com/1.1.0.json
Provider: yodlee.com
OpenAPI version: 3.0.1
Spec (JSON): https://api.apis.guru/v2/specs/yodlee.com/1.1.0/openapi.json
Spec (YAML): https://api.apis.guru/v2/specs/yodlee.com/1.1.0/openapi.yaml

Tools (72)

Extracted live via the executor SDK.

accounts.createManualAccount

The add account service is used to add manual accounts.
The response of add account service includes the account name , account number and Yodlee generated account id.
All manual accounts added will be included as part of networth calculation by default.
Add manual account support is available for bank, card, investment, insurance and loan container only.

Note:
A real estate account addition is only supported for SYSTEM and MANUAL valuation type.

accounts.deleteAccount

The delete account service allows an account to be deleted.
This service does not return a response. The HTTP response code is 204 (Success with no content).
accounts.evaluateAddress

Use this service to validate the address before adding the real estate account.
If the address is valid, the service will return the complete address information.
The response will contain multiple addresses if the user-provided input matches with multiple entries in the vendor database.
In the case of multiple matches, the user can select the appropriate address from the list and then invoke the add account service with the complete address.

Note:
Yodlee recommends to use this service before adding the real estate account to avoid failures.

accounts.getAccount

The get account details service provides detailed information of an account.

Note:
fullAccountNumber is deprecated and is replaced with fullAccountNumberList in include parameter and response.

accounts.getAllAccounts

The get accounts service provides information about accounts added by the user.
By default, this service returns information for active and to be closed accounts.
If requestId is provided, the accounts that are updated in the context of the requestId will be provided in the response.

Note:
fullAccountNumber is deprecated and is replaced with fullAccountNumberList in include parameter and response.
fullAccountNumberList, PII (Personal Identifiable Information) and holder details are not available by default, as it is a premium feature that needs security approval. This will not be available for testing in Sandbox environment.

accounts.getHistoricalBalances

The historical balances service is used to retrieve the historical balances for an account or a user.
Historical balances are daily (D), weekly (W), and monthly (M).
The interval input should be passed as D, W, and M to retrieve the desired historical balances. The default interval is daily (D).
When no account id is provided, historical balances of the accounts that are active, to be closed, and closed are provided in the response.
If the fromDate and toDate are not passed, the last 90 days of data will be provided.
The fromDate and toDate should be passed in the YYYY-MM-DD format.
The date field in the response denotes the date for which the balance is requested.
includeCF needs to be sent as true if the customer wants to return carried forward balances for a date when the data is not available.
asofDate field in the response denotes the date as of which the balance was updated for that account.
When there is no balance available for a requested date and if includeCF is sent as true, the previous date for which the balance is available is provided in the response.
When there is no previous balance available, no data will be sent.
accounts.updateAccount

The update account service is used to update manual and aggregated accounts.
The HTTP response code is 204 (Success without content).
Update manual account support is available for bank, card, investment, insurance, loan, otherAssets, otherLiabilities and realEstate containers only.

Note:
A real estate account update is only supported for SYSTEM and MANUAL valuation type.
Attribute isEbillEnrolled is deprecated as it is applicable for bill accounts only.

auth.deleteApiKey
This endpoint allows an existing API key to be deleted.
You can use one of the following authorization methods to access this API:
1. cobsession
2. JWT token
Notes:
This service is not available in developer sandbox environment and will be made availablefor testing in your dedicated environment.
auth.deleteToken

This endpoint revokes the token passed in the Authorization header. This service is applicable for JWT-based (and all API key-based) authentication and also client credential (clientId and secret) based authentication. This service does not return a response body. The HTTP response code is 204 (success with no content).
Tokens generally have limited lifetime of up to 30 minutes. You will call this service when you finish working with one user, and you want to delete the valid token rather than simply letting it expire.

Note:
Revoking an access token (either type, admin or a user token) can take up to 2 minutes, as the tokens are stored on a distributed system.
auth.generateAccessToken

Generate Access Token using client credential authentication.
This service returns access tokens required to access Yodlee 1.1 APIs. These tokens are the simplest and easiest of several alternatives for authenticating with Yodlee servers.
The most commonly used services obtain data specific to an end user (your customer). For these services, you need a user access token. These are simply tokens created with the user name parameter (loginName) set to the id of your end user.

Note: You determine this id and you must ensure it's unique among all your customers.

Each token issued has an associated user. The token passed in the http headers explicitly names the user referenced in that API call.

Some of the APIs do administrative work, and don't reference an end user.
One example of administrative work is key management. Another example is registering a new user explicitly, with POST /user/register call or subscribe to webhook, with POST /config/notifications/events/{eventName}.
To invoke these, you need an admin access token. Create this by passing in your admin user login name in place of a regular user name.

This service also allows for simplified registration of new users. Any time you pass in a user name not already in use, the system will automatically implicitly create a new user for you.
This user will naturally have very few associated details. You can later provide additional user information by calling the PUT user/register service.

Notes:
The content type has to be passed as application/x-www-form-urlencoded.
Upgrading to client credential authentication requires infrastructure reconfiguration.
Customers wishing to switch from another authentication scheme to client credential authentication, please contact Yodlee Client Services.

auth.generateApiKey
This endpoint is used to generate an API key. The RSA public key you provide should be in 2048 bit PKCS#8 encoded format.
A public key is a mandatory input for generating the API key.
The public key should be a unique key. The apiKeyId you get in the response is what you should use to generate the JWT token.
You can use one of the following authorization methods to access
this API:
1. cobsession
2. JWT token
Alternatively, you can use base 64 encoded cobrandLogin and cobrandPassword in the Authorization header (Format: Authorization: Basic )

Note:
This service is not available in developer sandbox environment and will be made available for testing in your dedicated environment. The content type has to be passed as application/json for the body parameter.

auth.getApiKeys
This endpoint provides the list of API keys that exist for a customer.
You can use one of the following authorization methods to access this API:
1. cobsession
2. JWT token
Notes:
This service is not available in developer sandbox environment and will be made available for testing in your dedicated environment.
cobrand.cobrandLogin

The cobrand login service authenticates a cobrand.
Cobrand session in the response includes the cobrand session token (cobSession)
which is used in subsequent API calls like registering or signing in the user.
The idle timeout for a cobrand session is 2 hours and the absolute timeout is 24 hours. This service can be
invoked to create a new cobrand session token.
Note: This endpoint is deprecated for customers using the API Key-based authentication and is applicable only to customers who use the SAML-based authentication.
The content type has to be passed as application/json for the body parameter.
cobrand.cobrandLogout

The cobrand logout service is used to log out the cobrand.
This service does not return a response. The HTTP response code is 204 (Success with no content).
Note: This endpoint is deprecated for customers using the API Key-based authentication and is applicable only to customers who use the SAML-based authentication.
cobrand.createSubscriptionEvent

Refer POST /configs/notifications/events/{eventName}.
The subscribe events service is used to subscribe to an event for receiving notifications.
The callback URL, where the notification will be posted should be provided to this service.
If the callback URL is invalid or inaccessible, the subscription will be unsuccessful, and an error will be thrown.
Customers can subscribe to REFRESH,DATA_UPDATES and AUTO_REFRESH_UPDATES event.

Notes:
This service is not available in developer sandbox/test environment and will be made available for testing in your dedicated environment, once the contract is signed.
The content type has to be passed as application/json for the body parameter.
cobrand.deleteSubscribedEvent

Refer DELETE /configs/notifications/events/{eventName}.
The delete events service is used to unsubscribe from an events service.
cobrand.getPublicKey

Refer GET /configs/publicKey.
The get public key service provides the customer the public key that should be used to encrypt the user credentials before sending it to Yodlee.
This endpoint is useful only for PKI enabled.
cobrand.getSubscribedEvents

Refer GET /configs/notifications/events.
The get events service provides the list of events for which consumers subscribed
to receive notifications.
cobrand.updateSubscribedEvent

Refer PUT /configs/notifications/events/{eventName}.
The update events service is used to update the callback URL.
If the callback URL is invalid or inaccessible, the subscription will be unsuccessful, and an error will be thrown.
Note: The content type has to be passed as application/json for the body parameter.
configs.createSubscriptionNotificationEvent

The subscribe events service is used to subscribe to an event for receiving notifications.
The callback URL, where the notification will be posted should be provided to this service.
If the callback URL is invalid or inaccessible, the subscription will be unsuccessful, and an error will be thrown.
Customers can subscribe to REFRESH,DATA_UPDATES and AUTO_REFRESH_UPDATES event.

Notes:
This service is not available in developer sandbox/test environment and will be made available for testing in your dedicated environment, once the contract is signed.
The content type has to be passed as application/json for the body parameter.

configs.deleteSubscribedNotificationEvent

The delete events service is used to unsubscribe from an events service.
configs.getPublicEncryptionKey

The get public key service provides the public key that should be used to encrypt user credentials while invoking POST /providerAccounts and PUT /providerAccounts endpoints.
This service will only work if the PKI (public key infrastructure) feature is enabled for the customer.

Note:
The key in the response is a string in PEM format.
This endpoint is not available in the Sandbox environment and it is useful only if the PKI feature is enabled.

configs.getSubscribedNotificationEvents

The get events service provides the list of events for which consumers subscribed to receive notifications.
configs.updateSubscribedNotificationEvent

The update events service is used to update the callback URL.
If the callback URL is invalid or inaccessible, the subscription will be unsuccessful, and an error will be thrown.

Note:
The content type has to be passed as application/json for the body parameter.
dataExtracts.getDataExtractsEvents

The get extracts events service is used to learn about occurrences of data extract related events. This service currently supports only the DATA_UPDATES event.
Passing the event name as DATA_UPDATES provides information about users for whom data has been modified in the system for the specified time range. To learn more, please refer to the page.
You can retrieve data in increments of no more than 60 minutes over the period of the last 7 days from today's date.
This service is only invoked with either admin access token or a cobrand session.
dataExtracts.getDataExtractsUserData

The get user data service is used to get a user's modified data for a particular period of time for accounts, transactions, holdings, and provider account information.
The time difference between fromDate and toDate fields cannot be more than 60 minutes.
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.
In the response body of the first API response, totalTransactionsCount indicates the total number of transactions the API will retrieve for the user.
This service is only invoked with either admin access token or a cobrand session.
Refer to page for more information.

Note:
This service supports the localization feature and accepts locale as a header parameter.

derived.getHoldingSummary

The get holding summary service is used to get the summary of asset classifications for the user.
By default, accounts with status as ACTIVE and TO BE CLOSED will be considered.
If the include parameter value is passed as details then a summary with holdings and account information is returned.
derived.getNetworth

The get networth service is used to get the networth for the user.
If the include parameter value is passed as details then networth with historical balances is returned.
derived.getTransactionSummary
The transaction summary service provides the summary values of transactions for the given date range by category type, high-level categories, or system-defined categories.

Yodlee has the transaction data stored for a day, month, year and week per category as per the availability of user's data. If the include parameter value is passed as details, then summary details will be returned depending on the interval passed-monthly is the default.

Notes:
1. Details can be requested for only one system-defined category
2. Passing categoryType is mandatory except when the groupBy value is CATEGORY_TYPE
3. Dates will not be respected for monthly, yearly, and weekly details
4. When monthly details are requested, only the fromDate and toDate month will be respected
5. When yearly details are requested, only the fromDate and toDate year will be respected
6. For weekly data points, details will be provided for every Sunday date available within the fromDate and toDate
7. This service supports the localization feature and accepts locale as a header parameter
documents.deleteDocument

The delete document service allows the consumer to delete a document. The deleted document will not be returned in the get documents API. The HTTP response code is 204 (success without content).
Documents can be deleted only if the document related dataset attributes are subscribed.
documents.downloadDocument

The get document details service allows consumers to download a document. The document is provided in base64.
This API is a premium service which requires subscription in advance to use. Please contact Yodlee Client Services for more information.
documents.getDocuments

The get documents service allows customers to search or retrieve metadata related to documents.
The API returns the document as per the input parameters passed. If no date range is provided then all downloaded documents will be retrieved. Details of deleted documents or documents associated to closed providerAccount will not be returned.
This API is a premium service which requires subscription in advance to use. Please contact Yodlee Client Services for more information.
holdings.getAssetClassificationList

The get asset classifications list service is used to get the supported asset classifications.
The response includes different classification types like assetClass, country, sector, style, etc. and the values corresponding to each type.
holdings.getHoldings

The get holdings service is used to get the list of holdings of a user.
Supported holding types can be employeeStockOption, moneyMarketFund, bond, etc. and is obtained using get holding type list service.
Asset classifications for the holdings need to be requested through the "include" parameter.
Asset classification information for holdings are not available by default, as it is a premium feature.
holdings.getHoldingTypeList

The get holding types list service is used to get the supported holding types.
The response includes different holding types such as future, moneyMarketFund, stock, etc. and it returns the supported holding types
holdings.getSecurities

The get security details service is used to get all the security information for the holdings
providerAccounts.deleteProviderAccount

The delete provider account service is used to delete a provider account from the Yodlee system. This service also deletes the accounts that are created in the Yodlee system for that provider account.
This service does not return a response. The HTTP response code is 204 (Success with no content).
providerAccounts.editCredentialsOrRefreshProviderAccount
The update account API is used to:
- Retrieve the latest information for accounts that belong to one providerAccount from the provider site. You must allow at least 15 min between requests.
- Retrieve the latest information of all the eligible accounts that belong to the user.
- Data to be retrieved from the provider site can be overridden using datasetName or dataset. If you do pass datasetName, all the datasets that are implicitly configured for the dataset will be retrieved. This action is allowed for single provider account refresh flows only.
- Check the status of the providerAccount before invoking this API. Do not call this API to trigger any action on a providerAccount when an action is already in progress for the providerAccount.
- If the customer has subscribed to the REFRESH event notification and invoked this API, relevant notifications will be sent to the customer.
- A dataset may depend on another dataset for retrieval, so the response will include the requested and dependent datasets.
- Check all the dataset additional statuses returned in the response because the provider account status is drawn from the dataset additional statuses.
- Updating preferences using this API will trigger refreshes.
- The content type has to be passed as application/json for the body parameter.
-----------------------------------------------------------------------------------------------------------------------------------------

Update All Eligible Accounts - Notes:
- This API will trigger a refresh for all the eligible provider accounts(both OB and credential-based accounts).
- This API will not refresh closed, inactive, or UAR accounts, or accounts with refreshes in-progress or recently refreshed non-OB accounts.
- No parameters should be passed to this API to trigger this action.
- Do not call this API often. Our recommendation is to call this only at the time the user logs in to your app because it can hamper other API calls performance.
- The response only contains information for accounts that were refreshed. If no accounts are eligible for refresh, no response is returned.
providerAccounts.getAllProviderAccounts

The get provider accounts service is used to return all the provider accounts added by the user.
This includes the failed and successfully added provider accounts.
providerAccounts.getProviderAccount

The get provider account details service is used to learn the status of adding accounts and updating accounts.
This service has to be called continuously to know the progress level of the triggered process. This service also provides the MFA information requested by the provider site.
When include = credentials, questions is passed as input, the service returns the credentials (non-password values) and questions stored in the Yodlee system for that provider account.

Note:
The password and answer fields are not returned in the response.

providerAccounts.getProviderAccountProfiles

The get provider accounts profile service is used to return the user profile details that are associated to the provider account.
providerAccounts.updatePreferences

This endpoint is used to update preferences like data extracts and auto refreshes without triggering refresh for the providerAccount.
Setting isDataExtractsEnabled to false will not trigger data extracts notification and dataExtracts/events will not reflect any data change that is happening for the providerAccount.
Modified data will not be provided in the dataExtracts/userData endpoint.
Setting isAutoRefreshEnabled to false will not trigger auto refreshes for the provider account.
providers.getAllProviders
The get provider service is used to get all the providers that are enabled, search a provider service by name or routing number and get popular sites of a region.
Searching for a provider using a routing number is applicable only to the USA and Canada regions.
The valid values for priority are:
1. cobrand: Returns providers enabled for the cobrand (Default priority)
2. popular: Returns providers popular among users of the customer

Only the datasets, attributes, and containers that are enabled for the customer will be returned in the response.
Input for the dataset$filter should adhere to the following expression:
<dataset.name>[<attribute.name>.container[ OR ] OR <attribute.name>.container[]]
OR <dataset.name>[<attribute.name> OR <attribute.name>]
dataset$filter value examples:
ACCT_PROFILE[FULL_ACCT_NUMBER.container[bank OR investment OR creditCard]]
ACCT_PROFILE[FULL_ACCT_NUMBER.container[bank]]
BASIC_AGG_DATA[ACCOUNT_DETAILS.container[bank OR investment] OR HOLDINGS.container[bank]] OR ACCT_PROFILE[FULL_ACCT_NUMBER.container[bank]]
BASIC_AGG_DATA
BASIC_AGG_DATA OR ACCT_PROFILE
BASIC_AGG_DATA [ ACCOUNT_DETAILS OR HOLDINGS ]
BASIC_AGG_DATA [ ACCOUNT_DETAILS] OR DOCUMENT
BASIC_AGG_DATA [ BASIC_ACCOUNT_INFO OR ACCOUNT_DETAILS ]

The fullAcountNumberFields is specified to filter the providers that have paymentAccountNumber or unmaskedAccountNumber support in the FULL_ACCT_NUMBER dataset attribute.
Examples for usage of fullAccountNumberFields
dataset$filter=ACCT_PROFILE[ FULL_ACCT_NUMBER.container [ bank ]] & fullAccountNumberFields=paymentAccountNumber
dataset$filter=ACCT_PROFILE[ FULL_ACCT_NUMBER.container [ bank ]] & fullAccountNumberFields=unmaskedAccountNumber
dataset$filter=ACCT_PROFILE[ FULL_ACCT_NUMBER.container [ bank ]] & fullAccountNumberFields=unmaskedAccountNumber,paymentAccountNumber

The skip and top parameters are used for pagination. In the skip and top parameters, pass the number of records to be skipped and retrieved, respectively.
The response header provides the links to retrieve the next and previous set of transactions.

Note:
1. In a product flow involving user interaction, Yodlee recommends invoking this service with filters.
2. Without filters, the service may perform slowly as it takes a few minutes to return data in the response.
3. The AuthParameter appears in the response only in case of token-based aggregation sites.
4. The pagination feature only applies when the priority parameter is set as cobrand. If no values are provided in the skip and top parameters, the API will only return the first 500 records.
5. This service supports the localization feature and accepts locale as a header parameter.
6. The capability has been deprecated in query parameter and response.
providers.getProvider

The get provider detail service is used to get detailed information including the login form for a provider.
The response is a provider object that includes information such as name of the provider,
provider's base URL, a list of containers supported by the provider, the login form details of the provider, etc.
Only enabled datasets, attributes and containers gets returned in the response.

Note:
This service supports the localization feature and accepts locale as a header parameter.
The capability has been deprecated in the response.
providers.getProvidersCount

The count service provides the total number of providers that get returned in the GET /providers depending on the input parameters passed.
If you are implementing pagination for providers, call this endpoint before calling GET /providers to know the number of providers that are returned for the input parameters passed.
The functionality of the input parameters remains the same as that of the GET /providers endpoint

Note:
The capability has been deprecated in the query parameter.

statements.getStatements

The statements service is used to get the list of statement related information.
By default, all the latest statements of active and to be closed accounts are retrieved for the user.
Certain sites do not have both a statement date and a due date. When a fromDate is passed as an input, all the statements that have the due date on or after the passed date are retrieved.
For sites that do not have the due date, statements that have the statement date on or after the passed date are retrieved.
The default value of "isLatest" is true. To retrieve historical statements isLatest needs to be set to false.
transactions.createOrRunTransactionCategorizationRules

The Create or Run Transaction Categorization Rule endpoint is used to:
Create transaction categorization rules for both system and user-defined categories.
Run all the transaction categorization rules to categorize transactions by calling the endpoint with action=run as the query parameter.

The input body parameters to create transaction categorization rules follow:
categoryId - This field is mandatory and numeric
priority - This field is optional and numeric. Priority decides the order in which the rule gets applied on transactions.
ruleClause - This field is mandatory and should contain at least one rule
field - The value can be description or amount

If the field value is description then,
1. operation - value can be stringEquals or stringContains
2. value - value should be min of 3 and max of 50 characters

If the field value is amount then,
1. operation - value can be numberEquals, numberLessThan, numberLessThanEquals, numberGreaterThan or numberGreaterThanEquals
2. value - min value 0 and a max value of 99999999999.99 is allowed
The HTTP response code is 201 (Created Successfully).
transactions.createTransactionCategory

The create transaction categories service is used to create user-defined categories for a system-defined category.
The parentCategoryId is the system-defined category id.This can be retrieved using get transaction categories service.
The categoryName can accept minimum of 1, maximum of 50 alphanumeric or special characters.
The HTTP response code is 201 (Created successfully).
transactions.deleteTransactionCategorizationRule

The delete transaction categorization rule service is used to delete the given user-defined transaction categorization rule for both system-defined category as well as user-defined category.
This will delete all the corresponding rule clauses associated with the rule.
The HTTP response code is 204 (Success without content).
transactions.deleteTransactionCategory

The delete transaction categories service is used to delete the given user-defined category.
The HTTP response code is 204 (Success without content).
transactions.getTransactionCategories

The categories service returns the list of available transaction categories.
High level category is returned in the response only if it is opted by the customer.
When invoked by passing the cobrand session or admin access token, this service returns the supported transaction categories at the cobrand level.
When invoked by passing the cobrand session and the user session or user access token, this service returns the transaction categories
along with user-defined categories.
Double quotes in the user-defined category name will be prefixed by backslashes (\) in the response,
e.g. Toys "R" Us.
Source and id are the primary attributes of the category entity.

Note:
This service supports the localization feature and accepts locale as a header parameter.

transactions.getTransactionCategorizationRules

The get transaction categorization rule service is used to get all the categorization rules.
transactions.getTransactionCategorizationRulesDeprecated

The get transaction categorization rule service is used to get all the categorization rules.
transactions.getTransactions

The Transaction service is used to get a list of transactions for a user.
By default, this service returns the last 30 days of transactions from today's date.
The keyword parameter performs a contains search on the original, consumer, and simple description attributes, replace the special characters #, &, and + with percent-encoding values %23, %26, and %2B respectively. Eg: for -Debit# , pass the input as -Debit%23.
Values for categoryId parameter can be fetched from get transaction category list service.
The categoryId is used to filter transactions based on system-defined category as well as user-defined category.
User-defined categoryIds should be provided in the filter with the prefix ''U''. E.g. U10002
The skip and top parameters are used for pagination. In the skip and top parameters pass the number of records to be skipped and retrieved, respectively. The response header provides the links to retrieve the next and previous set of transactions.
Double quotes in the merchant name will be prefixed by backslashes (\) in the response, e.g. Toys "R" Us.
sourceId is a unique ID that the provider site has assigned to the transaction. The source ID is only available for the pre-populated accounts. Pre-populated accounts are the accounts that the FI customers shares with Yodlee, so that the user does not have to add or aggregate those accounts.

Note
is made available for bank and card accounts and for the US market only.The address field in the response is available only when the TDE key is turned on.
The pagination feature is available by default. If no values are passed in the skip and top parameters, the API will only return the first 500 transactions.
This service supports the localization feature and accepts locale as a header parameter.
transactions.getTransactionsCount

The count service provides the total number of transactions for a specific user depending on the input parameters passed.
If you are implementing pagination for transactions, call this endpoint before calling GET /transactions to know the number of transactions that are returned for the input parameters passed.
The functionality of the input parameters remains the same as that of the GET /transactions endpoint.
transactions.runTransactionCategorizationRule

The run transaction categorization rule service is used to run a rule on transactions, to categorize the transactions.
The HTTP response code is 204 (Success with no content).
transactions.updateTransaction

The update transaction service is used to update the category,consumer description, memo for a transaction.
The HTTP response code is 204 (Success without content).
transactions.updateTransactionCategorizationRule

The update transaction categorization rule service is used to update a categorization rule for both system-defined category as well as user-defined category.
ruleParam JSON input should be as explained in the create transaction categorization rule service.
The HTTP response code is 204 (Success without content).
transactions.updateTransactionCategory

The update transaction categories service is used to update the transaction category name
for a high level category, a system-defined category and a user-defined category.
The renamed category can be set back to the original name by passing an empty string for categoryName.
The categoryName can accept minimum of 1, maximum of 50 alphanumeric or special characters.
The HTTP response code is 204 (Success without content).
user.getAccessTokens

The Get Access Tokens service is used to retrieve the access tokens for the application id(s) provided.
URL in the response can be used to launch the application for which token is requested.

Note:
This endpoint is deprecated for customers using the API Key-based authentication and is applicable only to customers who use the SAML-based authentication.
user.getUser

The get user details service is used to get the user profile information and the application preferences set at the time of user registration.
user.registerUser

The register user service is used to register a user in Yodlee.
The loginName cannot include spaces and must be between 3 and 150 characters.
locale passed must be one of the supported locales for the customer.
Currency provided in the input will be respected in the derived services and the amount fields in the response will be provided in the preferred currency.
userParam is accepted as a body parameter.

Note:
The content type has to be passed as application/json for the body parameter.

user.samlLogin

The SAML login service is used to authenticate system users with a SAML response.
A new user will be created with the input provided if that user isn't already in the system.
For existing users, the system will make updates based on changes or new information.
When authentication is successful, a user session token is returned.

Note:
The content type has to be passed as application/x-www-form-urlencoded.
issuer, source and samlResponse should be passed as body parameters.

user.unregister

The delete user service is used to delete or unregister a user from Yodlee.
Once deleted, the information related to the users cannot be retrieved.
The HTTP response code is 204 (Success without content)
user.updateUser

The update user details service is used to update user details like name, address, currency preference, etc.
Currency provided in the input will be respected in the services and the amount fields in the response will be provided in the preferred currency.
The HTTP response code is 204 (Success without content).
user.userLogout

Deprecated: This endpoint is deprecated for API Key-based authentication. The user logout service allows the user to log out of the application.
The service does not return a response body. The HTTP response code is 204 (Success with no content).
verification.getVerificationStatus

The get verification status service is used to retrieve the verification status of all accounts for which the MS or CDV process has been initiated.
For the MS process, the account details object returns the aggregated information of the verified accounts. For the CDV process, the account details object returns the user provided account information.
verification.initiateMatchingOrChallengeDepositeVerification

The post verification service is used to initiate the matching service (MS) and the challenge deposit account verification (CDV) process to verify account ownership.
The MS and CDV process can verify ownership of only bank accounts (i.e., checking and savings).
The MS verification can be initiated only for an already aggregated account or a providerAccount.
The prerequisite for the MS verification process is to request the ACCT_PROFILE dataset with the HOLDER_NAME attribute.
In the MS verification process, a string-match of the account holder name with the registered user name is performed instantaneously. You can contact the Yodlee CustomerCare to configure the full name or only the last name match.
Once the CDV process is initiated Yodlee will post the microtransaction (i.e., credit and debit) in the user's account. The CDV process takes 2 to 3 days to complete as it requires the user to provide the microtransaction details.
The CDV process is currently supported only in the United States.
The verificationId in the response can be used to track the verification request.

Notes:
This endpoint cannot be used to test the CDV functionality in the developer sandbox or test environment. You will need a money transmitter license to implement the CDV functionality and also require the Yodlee Professional Services team's assistance to set up a dedicated environment.
verification.verifyChallengeDeposit
The put verification service is used to complete the challenge deposit verification (CDV) process.
This service is used only by the customer of CDV flow.
In the CDV process, the user-provided microtransaction details (i.e., credit and debit) is matched against the microtransactions posted by Yodlee. For a successful verification of the account's ownership both the microtransaction details should match.
The CDV process is currently supported only in the United States.

Notes:
- This endpoint cannot be used to test the CDV functionality in the developer sandbox or test environment. You will need a money transmitter license to implement the CDV functionality and also require the Yodlee Professional Services team's assistance to set up a dedicated environment.
verifyAccount.initiateAccountVerification
The verify account service is used to verify the account's ownership by matching the transaction details with the accounts aggregated for the user.
- If a match is identified, the service returns details of all the accounts along with the matched transaction's details.
- If no transaction match is found, an empty response will be returned.
- A maximum of 5 transactionCriteria can be passed in a request.
- The baseType, date, and amount parameters should mandatorily be passed.
- The optional dateVariance parameter cannot be more than 7 days. For example, +7, -4, or +/-2.
- Pass the container or accountId parameters for better performance.
- This service supports the localization feature and accepts locale as a header parameter.
openapi.previewSpec

Preview an OpenAPI document before adding it as a source
openapi.addSource

Add an OpenAPI source and register its operations as tools