How our APIs work

General

  • You may not store any part of the authentication process, to include, but not limited to Username, Password, Security Questions or Answers in your application or back-end databases or servers. This is a security best practice. We do not want any elements of the member’s credentials stored on the device, vendor’s servers, or in the cloud. This can cause account vulnerability.
  • You may not store any Personal or Financial Information in your application or back-end databases or servers.This is a security best practice. We do not want any elements of the member’s personal/Financial stored on the device vendor’s servers, or in the cloud. This can cause identity theft vulnerability.
  • You can consider any non-200 HTTP response code an error – the returned data will contain more detailed information
  • We do our best to keep all of our APIs calls RESTful.

Versioning

We version our APIs within the URL. We also have 2 environments for you to use. One for Development, one for Production.

  • Development: https://api.dev.itsme247.com/{version}/
  • Production: https://api.itsme247.com/{version}/

API Access Keys

  • You may not reuse your API Keys between applications or Credit Unions. You will be assigned separate API Access Keys per application you create.
  • Reusing or combining keys restricts our ability to disable the application in the event a vulnerability or issue is identified.
  • It will limit our ability to accurately track usage for the application.
  • It will limit our ability to perform trend analysis.
  • Could impact the APIs ability to work correctly with credit union settings.
  • You may not share your API Access Key with any other party than yourself.

Access Control: Access is granted on multiple levels.

By Credit Union. Each Credit Union will have a Vendor list. We have the ability to turn off an entire Credit Union from API access at any time. This would remove access to all Vendors and all Applications for the Credit Union.

By Vendor. We have the ability to turn on/off a Vendor at any time. This would remove access to each application the vendor has associated with it, but leave the other Vendors for the CU as is.

By Application. Each vendor will have any applications it publishes assigned an access key to our APIs. Turning off an Application would remove access to all APIs enabled for the Application.

By API. Each Application will have APIs enabled or disabled based on assignment from CU*A. Access to each of these APIs on the Application level can be turned on and off at any time.

Passing Request Data

Request data is passed to the API by posting JSON objects to the API endpoints with the appropriate parameters. The documentation for each API call will contain more detail on the parameters accepted by the call.

API Limits

We reserve the right to limit your access to any and all API calls, which can include the amount of times you are able to call any particular endpoint in a specific time frame.

Blacklisting

If an application is found to be abusing the API system, it will be blacklisted. Blacklisted apps are unable to get a response from the CU*Answers Online Banking API. If you or your application has been blacklisted and you think there has been a mistake, you may contact us to request assistance.

The Flow of APIs

All APIs in the CU*Answers Online Banking API system require Access Keys and permissions. Please ensure you have all the proper paperwork filed in order to access our API network.

There are three different types of APIs in the CU*Answers Online Banking API system.

  1. Authentication
  2. Non-Authenticated
  3. Authenticated

Authentication

Authentication is part of a different type, as it’s a requirement to get into the system and use the “Authenticated” APIs. Authentication APIs are APIs that you call in order to Authenticate a member into the CU*Answers Online Banking System. The result of the Authentication API System is a Session and User Token that you will need to access all future Authenticated API calls. Some of these APIs are Non-Authenticated, some are Authenticated, which is why they are in a group of their own.

Authentication can be a tricky process, you will want to read the documentation carefully in order to get through the process correctly.

Non-Authenticated

Non-Authenticated APIs are APIs that do not require any type of Member Authentication, and can be used without Session and User Tokens.

Authenticated

Authenticated APIs are APIs that require a member to be authenticated into the system before you can call them. With these APIs you must always use a Session and User Token in order to call them and return a result.

Session Token

A Session token is received as you successfully complete Authentication. This token will last for 5 minutes while a member is still authenticating into the system. As soon as a member is fully authenticated, this token will last for 15 minutes. After this token times out (pre or post Authentication), it will become invalid and can no longer be used. A member will need to re-Authenticate in order to get a new token. Any API calls using an invalid token will be denied. Session Tokens can be renewed through the Refresh Tokens API. The will auto-renew upon every API call after it’s created. This token is specific to the member that was authenticated, and cannot be transferred.

User Token

A User token is received as you successfully complete Authentication. This token will last for 5 minutes when Authenticating into the system. As soon as a member is fully authenticated, this token will last for 15 minutes. After this token times out (pre or post Authentication), it will become invalid and can no longer be used. A member will need to re-Authenticate in order to get a new token. Any API calls using an invalid token will be denied. User Tokens can be renewed through the Refresh Tokens API. The will auto-renew upon every API call after it’s created. This token is specific to the member that was authenticated, and cannot be transferred.

Session and User Tokens are similar in function, but for security purposes, we tie them together to a specific member when logging into our system. You must pass both tokens in all API calls as soon as you receive them (which will be the very first Authentication API Call.)