In order to use CU*Answers developed APIs, and depending upon who the developer may be (e.g. outside 3rd party), API project type, desired Test environment, etc., the Developer’s Help Desk will require various paperwork to be completed. In order to best determine which Agreements may be applicable, please schedule a call with the DHD to initially review your API project strategy and desired goals. This early collaboration is very beneficial per our gaining preliminary insight to your overall API project, providing additional assistance for proceeding and delivering the appropriate Agreements for your review.
Once all necessary Agreements have been fully executed, you can proceed with requesting Development API (test) key sets. Depending upon the applicable Agreement/ Schedule(s) and other criteria, you will be provided a generic development API key to begin development against either a test CU*BASE credit union (e.g. Bedrock Test CU), or potentially, a real CU*BASE client configuration with staged settings and member data. In order for live Member Information to potentially be provided to a credit union’s API Developer, you must execute this Authorization to Release Member Information Form. This Authorization Form permits CU*Answers to create a test environment that closely matches your credit union’s CU*BASE production environment. Because this test environment could contain real data and CU*BASE configuration criteria, an authorized individual from the credit union must complete this Authorization Form, even if the developer is a credit union employee.
Note: You must have a unique key for each application or API consumer for each client. For example, if you are making a mobile application, you must have a unique API key for iOS and a unique key for Android versions of your app. In addition, you must have unique keys for each client you are serving.
Following this initial API Development strategy, the process will then normally follow the steps as shown within the Getting Started with APIs page.
Additionally, CU*Answers API development is divided in to multiple strategies that align with the business objectives of CU*Answers. While many APIs fall in to multiple categories, below is a high-level overview of these key strategies and links to view examples of some API documentation:
Member Interaction
This strategy will develop and consume APIs that allow individual credit union members to interact with their financial and personal information in a variety of systems. These systems will be ones developed and provided by CU*Answers such as It’s Me 247 desktop and mobile web banking, mobile apps, and MAP/MOP, but will also be utilized through applications developed by external vendors or even by credit unions themselves. This is a JSON based API.
Credit Union Information
This strategy provides a group of APIs that allow an application to access both the products/services that a CU provides and the configuration and settings associated with each. These are often JSON based APIs.
Member Information
This strategy provides a group of APIs that allow an application to get information about the member. In general, this is not a member interacting with the request, but an application doing so to gain the needed information to better understand the member information.
Loan Origination System (LOS)
This strategy will develop a robust suite of APIs that will provide information and integration with our four LOS initiatives: soup-to-nuts, ready-to-look, ready-to-book, and web-based. These are often This is an XML based APIs.
CU*BASE
This strategy will provide a set of APIs that provide the functionality of key CU*BASE functions. Ranging from the multiple teller platform initiative to web-based dashboards accessible through CU*BASE, these APIs will give the flexibility to adjust our product strategy while providing the building blocks needed for the future. These APIs are often JASON based APIs.
Third Party Integrations
This strategy works in conjunction with the DHD process and creates or leverages existing APIs for external products or services. Most of this development is to work with vendors to integrate/leverage.