API Update: Transactional.sendTransaction

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
Using custom fields with the check_antispam_fields parameter

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:


 Back to MARCH 2016 (RELEASE 16.3)