Introduction

The Alerts API allows financial institutions to provide their customers and members with the ability to set, manage and receive alerts about important account, transaction and other information.

The service type in the developer portal is Alerts and Messaging, and the service subType is db-messaging-services.

This service uses a v2 authentication token and requires the token to be generated with scopes as alertMgmt:read, alertMgmt:write for alerts type and template. 

For alert preferences, the required scopes are alertPref:read, alertPref:write. 

For publishing events, the required scope is alerts:publish. 

To view the alert history, the required scope is alertHist:read.

What is Supported?

The Alert Types API provides methods for carrying out the following tasks:
Create: The create method of the API establishes a particular alert type.

• The type is set for a given financial institution, set to a unique ID value, named and set to active (available for use) or inactive (not available for use).
• The specific alert type available in the system is set (e.g., ATM withdrawal or Visa low balance).
• The broad domain of alert event is set (e.g., an account event, a transaction event or a notification event).
• The category of event is set (e.g., balance or payment).
• The account types that can use this event type are enumerated.
• The channels the event notification can use are identified (e.g., email or SMS).
• If the alert type is for an external vendor event, the vendor ID is set.

Read:A list of all created alert types can be retrieved using this method.

• The values set for each alert type stored are sent in the response.
• All types created (active or inactive) are retrieved.

Update: Values forexisting alert type records can be updated and modified.

Delete: Specific alert types that are no longer needed can be deleted fromthe database.

The Alert Templates API provides methods for carrying out the following tasks:
‍
Create: The create method of the API establishes a particular alerttemplate.

• The template is set for a particular financial institution, given a unique ID value, named and set to be in draft, archived or published state.
• The types of content the template can be used with are identified (e.g., email subject, email body, SMS body, etc.).
• The channel through which the template can be used is identified (e.g., email, SMS or push).
• If the template is for an event initiated by a third party, the TPV is named.
• The language (e.g., locale) of the template is identified (e.g., U.S. English, Spanish, etc.).

Read: A list of all created alert templates can be retrievedusing this method.

• The values set for each alert template stored are sent in the response.
• All templates created, whether in draft, archived or published state, are retrieved.

Update: Values for existing alert template records can be updatedand modified.

Delete: Specific alert templates that are no longer needed can be deletedfrom the database.

The Alert Preferences API provides methods forcarrying out the following tasks:

Create: The create method of this API establishes an alert the end user wantsto be triggered for a particular event.Some characteristics of an alert preference are:

• A unique ID for the preference record, financial institution ID, customer ID, the name of the alert and a flag to set the alert preferences as a default for a particular event.
• The channels the alert is to use for communication (e.g., email, SMS or push).
• If the event will come from an external vendor, the ID of the external vendor.
• The account to be watched for an event identified by the financial institution’s account number, card number or external account number.

Read: This call can be used by the end user to call up and review some or all created preferences. It can also be used to read and use the preferences set by the end user when an event occurs.

• The call can be filtered by a variety of criteria, including alert type, account and institution ID.

Update: Values for existing alert preferences records can be updated and modified.

Delete: Specific alert preferences are no longer needed and can be deleted from the database.

The Alert Events API provides only one method, a call to indicate an event has occurred. The API then, in turn, takes the data passed in the request and initiates sending the alert. It uses the resources previously established—the alert type and its associated template and the end user’s preferences—to send the alert notification.
‍
The inbound call to this API will indicate the event is one of two possible types:

An event: Related to the end user’s accounts or transactions (e.g., the checking account balance is below a set threshold or a payment exceeds a set threshold).

A notification: A message sent by an external party (such as Visa) that requires no processing by the alerts system itself that must be sent to the end user.
‍
The Alert History API provides methods for carrying out the following tasks:

• Read: Get alert history data using parameters (e.g.,     account, date, etc.).
• Read: Get alert history data using content, history or event IDs.