Alert Info

To view Alert Info, navigate to All Alerts > Click on the desired Alert > Alert Info tab

This section contains information about the Alert, such as:

1. Channels for which the Alert has been configured along with information about the default and fallback channels if the channel order is sequential sending.
2. Request Details:

   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: a"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>}, "sender_attributes": {<list of the API attributes used for evaluating the sender to be selected>}, "personalized_attachments": {<list of the attributes used for sending attachements>}, "live_activity_attributes": {<list of attributes used to manage the lifecycle, static data, and dynamic state of an iOS Live Activity>}, } } 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.

3. Channel-level message previews If you created a push notification with Live Activity or Live Activity with Push Fallback as the message type, the following preview appears:
   The Live Activity UI is managed and rendered entirely by the SDKs. Therefore, the preview displays the JSON payload sent to the device rather than the final visual output. For more information, refer to Transactional Live Activity.

   

You can test the Alert on an external console using the code snippets in different languages, as shown below.

For more information, refer to Test your Alert.

• The Alert ID or Reference ID mentioned above in the code snippets must be used while sending Live Alerts. In case you use the Test Alert ID that is available during Alert creation, the request will fail.
• The logs get populated instantaneously when an API request is received, and you can view them in the Alert Logs tab.