Creating email broadcast REST vs XML

API Q&A
1

Using the XML API, creating an email broadcast sent to multiple contacts is simple enough.
https://developer.infusionsoft.com/docs/xml-rpc/#email-send-an-email
You just supply the ID#s of all the contacts you want to send the email to in an array, send the email content a single time, and done.

I want to move to using the new REST API so that I get the Email IDs returned as a response and can later query them for open status, etc.
https://developer.infusionsoft.com/docs/rest/#!/Email/createEmailsUsingPOST

It seems like you need to supply an individual ‘email’ for each contact as the ContactID field no longer accepts an array. Meaning, if I was going to send an email broadcast to 100 users, I’d have to supply 100 copies of the email bodies, subject lines, and each individual contact ID.

Is that correct? It seems a bit less efficient, but if that’s the way its done then so be it. I just want to check before I wire it up.

Thanks

2

@Matt_Summers, you should note that that the REST endpoint isn’t sending emails, but is used to record that communications have been sent to/from a contact. We do have plans to enable REST-based email sending in the future, but it is not available yet.

3

Thanks. That explains it. Glad I didn’t spend a lot of time on that.

Is there a suggested approach for sending a batch of emails and then later tracking them? The XML endpoint only returns a boolean.

I was hoping that with a list of email ID# I could query them for their status, or maybe even subscribe to an event hook.

4

Unfortunately there isn’t a good method for that at the moment. Querying GET /emails will show you the metadata about the recent emails that have been sent for the moment.

I’ll pass along the request for an Email RestHook event to our product manager, though!

5

Thanks. With the XML I can continue to send, and I bet I can capture the Email ID#s if I approach it carefully – I would know their approximate send times and subject lines and could pick them out of the /emails feed and make a note of the ID# at that time.

But then revisiting the metadata at a later time to prepare an ‘opened’ report would probably involve /emails/{id} one at a time. That’d have to be done on off-peak hours at least, and certainly not in real time. That would just be a bunch of busywork for both our systems. Hmmm… Might have to shelve this until we can get an email resthook.

6

It’d be great if we can get an email resthook. Is this still going to be implemented?