I'm using the REST API to send emails and currently have five test emails. Two of these never go to a 'Queued' status in the Triggered Send definitions after hitting the API, despite getting a 202 Accepted response. All responses from the API have hasErrors: "false" and messages: ["Queued"] in the JSON reply.

I'm testing using curl with the command

curl -i --header "Content-Type: application/json" --header "Authorization: Bearer <token>" --data @key:failing_template.json https://www.exacttargetapis.com/messaging/v1/messageDefinitionSends/key:failing_template/send

and with the following data in the file failing_template.json

    "To": {
        "Address": "[email protected]",
        "SubscriberKey": "[email protected]",
        "ContactAttributes": {
            "SubscriberAttributes": {
                "MemberFirstName": "Test Firstname",
                "MemberLastName": "Test Lastname",
                "SomeAmount": 123.45

There's pretty much no difference between what I'm sending for API calls which actually end up sending an email and ones that don't.

Things I've checked

  • Triggered Send has any changes published and is started.
  • External Key in the Triggered Send matches the key value in the API URL.
  • Triggered Send is associated with the correct DE.
  • All data sent has correct names and values for the DE associated with the Triggered Send.
  • Changing the external key of the triggered send and saving and publishing changes.

Similar to this question, which appears to not have been resolved either

1 Answer 1


This actually turned out to be an issue with data types, both of which return 202 Accepted headers from the API but then silently fail, never to be seen again.

Number fields don't like decimals

Sending a decimal or string with a decimal in it to a field that expects a number succeeds from the API end, but fails somewhere between the API endpoint and the Triggered Send.

For example, if both the First and Second columns in the DE have the data type Number then this will fail

"First": 1234.56,
"Second": "1234.56"

But this will succeed

"First": 1234,
"Second": 1234

I didn't test a quoted field with an integer. In all fairness this should have been expected, since the documentation does say

You cannot import decimal values into a column with this data type. If you need to import decimal values, use the Decimal data type instead

Date fields are finicky

This one was a little weirder, despite the documentation saying

  • Attributes of a date type will accept dates in various formats, such as 1/1/2005 or January 1, 2005
  • You can add a HH:MM time value following the date value, such as 12/12/2012 12:12 PM.

The following date formats seem to fail due to D-M-Y formatting despite any locale settings. The expected format seems to be M-D-Y

"DateField": "21-11-2014",
"DateField": "21-11-2014 11:29",
"DateField": "21-11-2014 11:29 PM",
"DateField": "21/11/2014",
"DateField": "21/11/2014 11:29",
"DateField": "21/11/2014 11:29 PM",

The following seem to fail due to inclusion of a timezone

"DateField": "21 November 2014 11:29 PM EST",
"DateField": "21 November 2014 23:29 EST",

The following seem to work, since they either do Y-M-D formatting or are in the expected "D F Y" format.

"DateField": "2014-11-21 11:29",
"DateField": "2014-11-21 11:29 PM",
"DateField": "2014/11/21 11:29",
"DateField": "2014/11/21 11:29 PM",
"DateField": "21 November 2014",
"DateField": "21 November 2014 11:29",
"DateField": "21 November 2014 11:29 PM",
"DateField": "21 November 2014 23:29:35",
"DateField": "21 November 2014 23:29:35 PM",

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .