Test Alert

You can test your Alert before it is published in the third step of Alert creation. This option lets you test your alert on the chosen channels before publishing it, as shown below.

info	Note This step is recommended (but optional) to ensure the API integration is set up correctly and the personalization is rendered properly.

How to test the Alert before publishing?

You need to pass a few values to the request copied from the Dashboard. They are the Authorization Header, MOE-APPKEY, request attributes, and personalization attributes (if any).

Build Authorization Header

MoEngage uses Basic Authentication. Use the Workspace ID and API Secret to generate HTTP Auth Header, as explained here.

Copy Request

You can also copy the sample request in any of the supported languages from the Test Request section in the dashboard and test it on an external console using the copy to clipboard icon.

Copy Workspace ID

The request header MOE-APPKEY should contain the Workspace ID value of your MoEngage Account.

Test Alert ID

A Test Alert ID is provided on the Dashboard to send this Test Alert request to an external console. This value gets passed in the request automatically.

Note: This would differ from the Alert ID for the published Alert.

Test Alert Reference Name

Test Alert Reference Name is configured while adding the alert on the Dashboard to send this Test Alert request to an external console. This reference name can be used to test the alert.

info	Information This is different from the Reference ID for the published Alert.

Attributes

The following attributes need to be passed in the request:

Request Field	Mandatory	Description
MOE-APPKEY	Yes	This is the Workspace ID of your MoEngage Account. The Workspace ID uniquely identifies your MoEngage workspace. This value gets auto-populated in the test request (supported in multiple languages).
Authorization	Yes	This is the Base64 encoded authorization header (APPID:APISECRET) that needs to be passed for authentication.
alert_id	Yes	This is the Test Alert ID generated to test the request from an external console. This value is auto-populated in the request.
alert_reference_name	No	This is the reference ID that you can add while creating the alert.
user_id	No	This field is provided by your brand and should be pasted in the request being tested. This field is the Client ID and identifies the user to whom the Alert is being sent. This is essential for event mapping back to the user. If an Invalid User ID or non-existent User ID is shared and API request has valid recipient details, a new user profile would be created with valid recipient details. If User ID is not present in the request, the request will still be processed, provided the recipient details are available. However, the events will not be logged to any user in MoEngage. For more information, refer to User identification for sending the Alert.
transaction_id	Yes	This field needs to be provided by the brand and pasted in the request being tested. This field identifies the transaction about which the Alert is being sent to the user. Moengage will store the transaction ID against the uniquely generated request ID. Ensure that the transaction_id is unique for every request you send to the user. This is also used to support idempotency.
payloads	Yes	This field contains the channel-level payload that, in turn, contains the user details and personalization attributes. The payload has the following structure: "payloads": { "<Channel_Name>": { "recipient": "<pushtoken/mobile number with country code/email id>", "locale": "<required locale version to be sent to the user>" "personalized_attributes": { <list of the attributes to be personalized> } } } The recipient field in the payload identifies the user to whom the Alert has to be sent. For more information, refer to User identification for sending the Alert.

User identification for sending the Alert

The API processes the user identity information shared in the request and identifies the user to whom the communication needs to be sent, as shown below.

The channel level payload's recipient field is looked at first and based on the value provided for the recipient there; the Alert is sent to the mobile number/email ID or push token specified. In case the recipient details are not available, the user_id has to be passed in the request, failing which, the request will be dropped. If the user_id (the ID field in the User Profile)is available in the payload and the recipient details(mobile number/email ID/active push token) for the specified channel are available in the user profile, then the Alert is sent.

In case of recipient details are available and a new user_id is shared a new profile will be created with the recipient details.

info	Note Only the five most recently active device tokens available in the User Profile will be considered for sending the Alert for the Push channel. The recipient details are fetched from the User Profile if user attributes are enabled. For more information, refer to Enabling User Attributes.

Once all the necessary information is added to the request, send the request from the external console.

Testing the request in Postman

To test in Postman, do the following:

1. 1. Click on the copy & open Postman icon to copy the cURL and import it in Postman.
  2. Add the authentication details by using the authorization section. Add the Workspace ID as the username and the API Key as the password.
  3. The imported cURL will contain the payload details. Add the Email ID, Phone Number, and other attributes (user_id, transaction_id, personalization, if any).
  4. Click on Send in Postman. This will send the request to the Send Inform API.

For information about responses, error codes, and sample responses, refer to Inform API Response.

After you've tested the Alert, the Test Alert Logs get populated with details about the request's status. For more information, refer to Test Alert Logs.