Overview
Prepared messages can be sent through Automations/Whiteboards or triggered through API calls.
When sending a prepared message via API, the message can include standard attributes and related data in its subject and body. It can also use parameters: values supplied as part of the API request that are specific to that individual message and recipient.
Unlike system or custom attributes, parameter values are not stored in Engage. They exist only in the context of the prepared message at the time it is sent.
As a result, parameter values cannot subsequently be retrieved or viewed through the Engage user interface or through read online links.
They may be present temporarily in system logs, depending on the available logging and retention.
Limitation with Read Online Messages
Because API parameters are temporary, point-in-time values, they are no longer available when a recipient later opens the Read Online version of a message.
The Read Online version can resolve data that remains available in Engage in the viewer’s profile, including:
System attributes
Custom attributes
Related data associated with the member viewing the page
However, placeholders that reference API parameters cannot be resolved. These placeholders will therefore appear blank in the Read Online version of the message.
This means that the content displayed in Read Online may differ from the message originally received by the recipient.
Solutions and Workarounds
Option 1: Remove the Read Online Link
Complexity: Low
For prepared messages that use API parameters, remove the Read Online link from the message template.
This prevents recipients from accessing a version of the message in which parameter-based content can no longer be displayed.
Option 2: Provide Fallback Content with InsertIf
Complexity: Medium
Update the prepared message template to conditionally display parameter values using InsertIf.
The template can check whether the relevant parameter array key contains a value. If the value is blank or unavailable, the template can display appropriate default or fallback content instead.
This allows the Read Online version to remain accessible without leaving blank areas where parameter values were originally displayed.
Option 3: Replace API Parameters with Custom Attributes
Complexity: High
Where the values need to remain available after the message has been sent, consider replacing API parameters with custom attributes.
Custom attributes are stored against the member's profile and can therefore remain available when the Read Online version is generated.
This approach requires changes to both the prepared message template and the client-side API implementation:
Replace parameter placeholders in the prepared message with the appropriate custom attributes.
Update the API integration to write the required values to the member's profile.
Once the profile has been updated, trigger the prepared message send API call.
Important Consideration
API parameters are appropriate for temporary values that are only required when a message is sent.
If a value needs to be available later—for example, when displaying the message through Read Online—it should be stored as persistent member data, such as a custom attribute.
When using custom attributes as a replacement, also consider whether subsequent updates to those attributes could cause the Read Online version to display values that differ from those present when the original message was sent.