Agreed. This kind of domain logic doesn't really belong in a generalized mail API. It should be easy enough to build in to your app by recording the last email date/time

I think in the basic example I gave, that's fine, but it quickly becomes unwieldy.

Take for example the A/B testing of pricing. I'd like to offer some customers an infinite free trial while others only get a month free after which time they have to upgrade. The email flow for each of these types of customers would be quite different over the first couple of months. Different actions would trigger different emails at different times. That logic is not really something you want deep in your app (as I say, that's more marketing logic than app logic).

Looking through the other links provided in the sibling posts I'm starting to think the right way of doing this is using an event tracking system (Mixpanel type idea, but maybe storing that information internally). Then you have a rules engine outside of the app to send out the emails. It then becomes trivial to segment as in my a/b testing example, or to not send out more than one of a certain type of email a day etc.

Thanks for all the thoughts on it though - it's helped to push me in the right direction.