Updating Connectivity Plug-ins for Account Error Codes

This procedure provides a generic approach for updating your Financial Institution Connectivity Plug-in to use standardized error codes for account-specific errors. Implement this update to ensure that account-level error reporting in NetSuite is actionable and consistent.

Note:

Standardized error codes will be adopted by the Bank Feeds SuiteApp in a phased rollout, beginning with Yodlee in the upgrade targeted for March 11, 2026. Support for MX and Salt Edge is planned for a subsequent release in April 2026. Until these upgrades, only custom or third-party plug-ins that have been updated as described in this topic will surface standardized error codes.

To update your connectivity plug-in to use standardized error codes for account-level errors:

Identify all account-level failure scenarios.

Review your plug-in's logic in methods like getAccounts and getTransactionData. Find every place where an error is returned or surfaced for a specific bank account (such as "account locked," "incorrect credentials," or "consent expired").
Map each failure scenario to a standardized account error code.

For each account-level error scenario you handle, map it to the corresponding standardized error code listed in the Bank Import Error Codes Reference. Double-check all branches of your error handling, including rarely encountered or edge case errors from your banking APIs. This step will ensure that every account-level error scenario is mapped to a standardized error code.
Update your code to use the errorCode field instead of failureReason.

For usage details and an example, see errorCode .

If your plug-in already preprocesses failure information from the external source, update that mapping logic to use standardized error codes. Then, supply the code using the errorCode property. For example, your plug-in might preprocess external errors by mapping them to your own custom error messages or internal codes.

Note:
The failureReason property is being phased out and will be ignored in a future release. Make sure your code always returns errorCode for all relevant error scenarios. Free-text failure reasons are targeted for removal in a future release, but you're strongly encouraged to update your plug-in as soon as possible.
1. Update getAccounts:
  
  Note:
  The provided code samples are examples and should be adapted to your plug-in implementation.
  
  Legacy approach (before standardization)
  
  The plug-in preprocesses the failure reason, maps it to the appropriate error code, and returns something like the following using the errorCode property.
```
                    context.addAccount({
    accountMappingKey: account.accountMappingKey,
    accountType: account.accountType,
    currency: account.currency,
    groupName: account.groupName,
    failureReason: account.failureReason
}); 

                  
```
  Standardized approach (required for standardized error codes)
```
                    // Pre-process failure reason and map to error codelet errorCode = '';
if (account.failureReason == 'Account locked.') {
    errorCode = '2000000100';
}
// Continue for all other possible error scenarios.

context.addAccount({
    accountMappingKey: account.accountMappingKey,
    accountType: account.accountType,
    currency: account.currency,
    groupName: account.groupName,
    errorCode: errorCode
}); 

                  
```
  Set the name property to 'BANK_IMPORT_STANDARD_ERROR'.
  
  Set the description property to the standardized error code that corresponds to the failure scenario. For a list of error codes and scenarios, see Bank Import Error Codes (Reference).
2. Update getTransactionData:
  
  Legacy approach (before standardization)
  
  The plug-in preprocesses the account data but still returns failureReason to core.
```
                    accountRequests.forEach(function (accountRequest) {
    // process...
    accountRequest.failureReason = response.account.failureReason;
});
context.returnAccountRequestsJSON({accountsJson: JSON.stringify(accountRequests)}); 

                  
```
  Standardized approach (required for standardized error codes)
  
  The plug-in preprocesses failures, maps each to a standardized error code, and includes the standardized code using the errorCode property in the returned object. For example:
```
                    accountRequests.forEach(function (accountRequest) {
    // process...const failure = response.account.failureReason;
    if (failure === 'Account locked.') {
        accountRequest.errorCode = '2000000100';
    }
    // Continue for all other possible error scenarios.
});
context.returnAccountRequestsJSON({accountsJson: JSON.stringify(accountRequests)}); 

                  
```
  In each case, ensure your logic now returns errorCode and not failureReason to NetSuite.

Additional Guidance

For more guidance, do the following:

Test your plug-in by simulating account-level failures and confirm that the UI displays the expected standardized error codes and messages. For more information, see Conditions for Testing a Financial Institution Connectivity Plug-in.
For details about updating connectivity plug-ins for import-level errors, see Updating Connectivity Plug-ins for Import Error Codes
For details about updating parser plug-ins for parser-level error codes, see Updating Parser Plug-ins for Parser Error Codes.

For more information about import error codes or mapping scenarios, see Bank Import Error Codes (Reference). If you need assistance, contact NetSuite Support.

To update your connectivity plug-in to use standardized error codes for account-level errors:

Additional Guidance

Related Topics