A new argument has been added to the Transactional.sendTransactional API method: check_antispam_fields. Primarily to support anti-spam compliance programs such as CASL, this argument determines if a transactional message should be sent or not based on subscriber status values recorded in custom fields.
In conjunction with this API update, the ability to associate specific fields for capturing a subscriber’s compliance status and date is introduced. Status values recorded (“implied” or “express”) in these fields, when combined with a compliance date, help determine if a transactional message should be sent.
To use this argument, set this element to ‘1’ if compliance custom fields should be checked for status and date.
New response codes and information on using this method and understanding the results:
| Condition | Response Code | Response Text |
|---|---|---|
| Message not sent, one or both compliance fields do not exist | 465 | Did Not Send: One or both compliance fields do not exist |
| Message not sent, compliance status field contains an unrecognized value | 466 | Did Not Send: Compliance status is not a valid value |
| Message not sent, compliance not passed: implied status with date (compliance or date added) is two years or more, or has a null value (after grace period) | 467 | Did Not Send: Compliance date is past expiration or has a null value |
A new section for creating or choosing custom fields to be used for recording subscriber status can be found here: Administration > Configure Settings > Email Sending Defaults > Other System Options
Marketers can create new custom fields or select from existing ones to use for facilitating CASL compliance.
When using the “check_antispam_fields” flag to evaluate the contents of the Compliance custom fields, both a status and a date field must be present for the check to be performed. Message sends are then executed according to these rules:
