When you integrate the communication planning data feed in your newsletter system, you will need to retrieve the list of e-mails on a regular basis and decide what should be actually sent.
For this, we recommend following an approach to request our feed frequently at least once per hour (but possibly up to every 10 minutes)
Once the feed is collected several aspects have to be considered before sending the e-mail:
Should the email be sent immediately?
In general, we recommend sending the e-mail immediately and to ignore the indicated sent time.
Of course, you can schedule the e-mail to be sent later on, but if you request the feed frequently enough, the feed can be configured to only return you e-mails that should be sent in the coming X minutes as you know you will call the feed again later on.
alternatively, you can also do less frequent calls to the feed but then you will need to store the planned e-mails and schedule their sending on your side which is an additional effort.
What about transaction e-mails? Can I register a Webhook?
Yes, for cases like account creation confirmation, welcome mail, or other transaction e-mails you can use a Webhook instead of calling the feed.
This is only applicable though for cases where the number of e-mails to be sent is very small at a time (typically 1).
Typically, in the case of a Webhook, the data will be sent to the webhook and therefore would not be part of the feed. So an e-mail is either push to the Webhook or retrieved with the feed but they would never be in both.
How can I avoid missing any e-mail to be sent?
Let’s consider that you call the feed at time T and that you call it every 10 minutes.
We recommend that the feed returns not only what is to be sent from T to T+10.
We recommend that the feed returns to you all what is to be sent from T-30 to T+10.
This way even if your service fails once or twice it would still be able to catch up on the last half hour of e-mails automatically.
In case your setup is down for longer than 30 minutes you can also change the configuration of the feed temporarily until your server was able to catch up.
How can I avoid sending the same e-mail twice?
If you apply the logic of the prior point (T-30 to T+10) it is possible that you would receive the same e-mail twice but of course, should not send it twice.
Each e-mail has a unique ‘communication_id’ so you need to make sure you don’t send the same ‘communication_id’ more than once.
You have several possibilities to ensure it:
Make sure you always push the communication_history data before calling the feed. The feed is computed on demand and will check to only return you communication_ids which are not already in the existing communication_history data
Keep a record of sent communication ids on your side and skip any ids you already sent
Consider e-mails with a timestamp of T-30 to T only if you know that the prior runs failed
For safety, we recommend using both point 1 and point 2, this dual security is a very good idea to avoid ever sending any e-mail twice.
0 Comments