Why is this happening?
A while ago, we introduced a shiny new set of email editors that are much more flexible and powerful than our old editors. When they launched, we also created a new method (createEmail) that was tied to these new editors. While the old method (createEmailCampaign) still exists, it is becoming increasingly unreliable in its deprecated state. Even if your code is still working with createEmailCampaign, we highly recommend updating to createEmail to prevent unexpected and undesired behaviors from the system.
What do I do?
The methods are generally very similar. They have a few differences in nomenclature (outlined below) and what attributes are required. The change also takes setEmailCampaignContents out of the picture, so if you were using that to update your email campaigns, you’ll need to modify that workflow as well.
createEmail requires login and email arguments, and the email argument must include the following attributes:
Some of the types are slightly different between the two methods as we’ve updated the app’s vernacular; you’ll need to change them as follows: (old attribute) -> (new attribute)
- type -> email_type
- support_email -> reply_to_email
The method setEmailCampaignContent is incompatible with createEmail, so the changes you would make through it are distributed to setEmailCampaignAttribute and updateEmailContents.
setEmailCampaignAttribute is used to set or change the following attributes:
- support_email (which is treated the same as the reply_to_email)
updateEmailContents is used to set or change the following attributes:
As always, if you have any questions about what to change or how, shoot us an email at firstname.lastname@example.org and we’ll be happy to help.