Update Contact Preferences via REST API?

Your software
My Mautic version is: 4.1.2
My PHP version is: n/a
My Database type and version is: n/a

Your problem
My problem is:

I would like to update contact preferences via REST API but don’t see how. So perhaps it is not possible.

My company’s use case for Mautic is for marketing automation. The end user never interacts directly with Mautic. We create / update users within our own db, and then create / update contacts in Mautic using a subset of the user’s properties (via REST API). We allow users to manage their contact preferences through our app, not through Mautic directly.

Is there a suggested way to handle this?

If the REST API isn’t the way to go, then I think we’ll have to make sure our segments filter out contacts where we’ve set various properties to ‘false’. For example, include contacts where emailOptIn=true, or smsOptIn=true.

1 Like

hi @jobemkaar, have you found this function?
We are also in a need of setting subscription categories based on the app sign up form and adding a contact by REST.

Can anyone help?

Hi,
There are no subscription categories in Mautic.
You can create a custom field and update that via API
When you send the email / campaign, you can filter for the custom field.

Hi,
I have implemented subscription based on categories following this video Understanding Contact Preferences and Categories - YouTube
This comes with already built-in Preference center page, when user clicks “unsubscribe” from the email.
It works great and all when I tested by manually setting/unsetting categories on contact page. However I can’t see any REST for setting Contact Preference Center.

If I implement subscription status based on custom fields then I would have to reinvent the wheel and develop whole unsubscribe/resubscribe functionality.

You are right.
Have you tested if the category subscriptions are indeed considered when sending out segment emails?
If yes and it worked - what version of Mautic are you using?
Joey

@joeyk I’m on v4.4.3
When I tried just putting segment or email to category that didn’t affect anything.
But I can use segment filters based on a category, there is a field under Contact fields “Subscribed Categories” and the segments updated accordingly, so that is working and I can categorize segments.

It would be great to be able to programatically update the preference center settings. But in the end of the day the minimal need is:

  • adding Contact via REST
  • ability to mark them as “marketing consent”, either in initial “new” payload or in following update request
  • if none “marketing consent” (unsubscribed) then it must keep sending transactional emails

If I do not use preference center and contact is marked “doNotContact” the user won’t receive mandatory transactional emails (e.g. Password Reset).

3rd alternative I tried: Custom Preference Center Landing page where user can change his custom field and filter segments on it. I liked this one the most as I could also style it. But I did not find a option to set the Custom Preference Center page as default for all Emails - so it would have to be specified in each Email Settings, which is unmanagable.

I tried to solve this simplest use-case all day and it feels unachievable, I dunno if I’m just blind.
Any tips appreciated :slight_smile:

1 Like

Hi, yeah,
I just tested it, and having a global category or an email category won’t affect emails sent. But segments do, just as you mentioned. That is a really really good workaround, I’m glad you discovered it.
I think many marketers would use this option gladly.

Regarding your other questions:

  • You can add/edit contact via REST: Mautic Developer Documentation
  • You can create a custom field “marketing consent” and programatically edit it
  • You can exclude the contacts without marketing consent using filters from marketing emails.

I’m also surprised, but I couldn’t find a way changing contact category via REST. I also couldn’t find a way to edit it as campaign action. I agree it would be cool. I’m sorry it doesn’t work :frowning:

  • You can add/edit contact via REST: Mautic Developer Documentation
  • You can create a custom field “marketing consent” and programatically edit it
  • You can exclude the contacts without marketing consent using filters from marketing emails.

Yes, but this way users won’t be able to simply unsubscribe by hitting unsubscribe in an email footer, which is a must-have as well.
OFC I can change the URL of “unsubscribe” link in the footer to point to a form that would update customField - but to pair the form with a Contact the user has to retype his/her email address. No pairing by token which is normally found in unsubscribe page URI.

In the end I think I won’t avoid reinventing the un(re)subscribing “wheel”, including authorization. The unsub UX won’t be as friendly as it should be.
That is unfortunate as well as surprising that such a simple functionality is not there, since otherwise Mautic + Custom Objects plugin meet all other quite complex needs of ours.

there is another workaround you can try:
if you are using an outside code that calls the mautic API, but there is a specific thing that is not possible to do to API, but you can do it by submitting a mautic form, try this:
create the mautic form, have your code submit the form (make a POST HTTP REQUEST with header content type = application/x-www-form-urlencoded )

@leoschuler I actually tried that as well. Unfortunately to submit the frequency rules of a user you need a token, which is only encoded in HTML markup of the previous request. It’s so hacky it’s uncomfortable for me to put in production :thinking:

are you referring to the link tracking token from the e-mail? if that is the case you might try to work with a custom token, it could be a random key stored in a custom field or it could be the e-mail or id of the lead encrypted, so the link final link would be www.myapp-unsubscribe.com?track=<trackID> you can then use the trackID to figure out which email needs to be used to submit the form. just don’t use the raw data (email or leadID) so it could be easily exploit