Wanted: a developer API for MailPoet

MailPoet is an awesome plugin, and I love to implement it for my users and customers. It’s my goto-solution for newsletters, period.

When using MailPoet as a developer, it would be even more awesome if we could rely on an API for a number of simple actions.

Imagine the following automations:

You have a BuddyPress website where users can select from a list of interests (let’s say for example: Movies, Music, Sports, Travel…).

Now, imagine you could build a script that would test those selected topics (using built-in BuddyPress functions), and would subscribe the users to specific MailPoet lists.

MailPoet has documented ONE developer functionality, that is quite close to what we want:

The documented method:

$user_data = array(
'email' => $user->user_email,
'firstname' => $user->user_firstname,
'lastname' => $user->user_lastname);

$data_subscriber = array(
'user' => $user_data,
'user_list' => array('list_ids' => array($my_list_id1,$my_list_id2))

$helper_user = WYSIJA::get('user','helper');

This function is used when a user subscribes through the frontend… The limitation: if opt-in is globally requested, the user will get a confirmation request, he won’t be automatically added.

Now, you could disable the opt-in globally, and users will get added with this method – not bad!

But unfortunately, you typically have a public-facing subscription form where you DO want the opt-in to be active, and at the same time you want to run your fully automated process in the back-end… so there’s a need for another method.

By looking through the code of MailPoet, I came across the following functions:

$helper_user = WYSIJA::get('user','helper');

and this:

$helper_user = WYSIJA::get('user','helper');

I tried to use those functions for a project. First, everything seemed to work fine – on a small test site with a dozen of users, it allowed to sort them into lists as expected.

Unfortunately, when I tried to use it on a production site with about 400 WordPress/BuddyPress users, I noticed some errors and realized one thing: the WordPress user IDs are mostly matching the MailPoet IDs, but not always… so I was adding some users to the wrong lists. As a conclusion, we can’t rely on those functions to handle our WordPress users.

The question is: what would be needed, for a functional API?

Some ideas:

  • ask to which lists a user (email address) is subscribed to.
  • add WordPress user to a list (by ID or email address).
  • if the list has an automated welcome message, decide if the user should get it upon subscription.
  • remove a WordPress user and remove it from a list.
  • create a list.
  • delete a list.

Could that be a job for a custom plugin?