Changes to Transactional Mailers API
Historically the transactional mailers API (see Send Transactional Email) returned a unique transaction id if successful, otherwise it would return a status code along with a message.
On 1 November 2010, a slight change to this API is being introduced: a unique transaction id will be returned before mail delivery is attempted by Mimi. This means that you will not receive an immediate response on whether the mail delivery was successful or not.
To determine the status of your mailing you will need to use Transactional Mailing Status.
In other words, when you receive a status code of 200 along with a transaction id it means that your API call was successful, and that you should do an additional API call to determine if the mail was delivered or not.
How does this affect me?
▪ If you currently fire and forget your transactional mailings, this change will make no difference to you.▪ If you currently check the mailing status, you may now receive the @ignorant@ state which means the mailing is in the queue to be sent. Typically, the mailing will not spend more than a couple of seconds in the queue (and the @ignorant@ state).
▪ If you are relying on the 200 status code from the call to determine if your mailing has sent, you will need to start checking the status.
We have already rolled out changes which have given us a radical performance increase of the Transactional Mailing Status.
Why are you making this change?
This change improves the performance of the transactional mailing API (see Send Transactional Email), meaning we can respond to requests faster, queue transactional mailings if necessary and optimize the background processes that send the emails.
In general, this will also improve the performance of all API methods, as well the performance of Mimi in general.