Updating email preferences via API

Product Support

AI-generated summary

In a Support category discussion titled “Updating email preferences via API,” kgoetz sought help updating user email preferences (e.g., enabling Activity Summary, disabling Mailing List Mode) via the Discourse API, encountering issues with both curl and pydiscourse. Initial attempts using /users/username failed with HTML output instead of JSON. blake clarified that the correct endpoint is /u/username.json via a PUT request, providing example parameters. kgoetz confirmed success using this method with curl and later worked around pydiscourse’s lack of PUT parameter support by calling _request directly. They also asked why some settings are only accessible via /u/username and not /users/username. blake explained that /u was introduced for shorter, prettier URLs and that most /users routes have /u equivalents, though some may still be missing. codinghorror suggested identifying and fixing any remaining inconsistencies to ensure /u works universally.

1

Hi,
I’ve spent several hours trying to update users email preferences via the api, and haven’t had much luck. Specifically, I want to enable Activity Summary and turn of Mailing list mode.

Has anyone done this and succeeded and can point me at where I’ve gone wrong?

Some examples below.

I tried this with and without the user/user option layers. Unfortunately there isn’t a meaningful error, just a page of html spat out.

$ curl -X POST --data ‘user: { user_option: {“mailing_list_mode_frequency”: 1, “email_direct”: True, “mailing_list_mode”: False, “email_digests”: True, “email_in_reply_to”: True, “enable_quoting”: True, “like_notification_frequency”: 1, “email_always”: True, “email_private_messages”: True, “email_previous_replies”: 1, “include_tl0_in_digests”: True}}}’ “https://discuss.example.com/users/karl_goetz?api_key=[..]&api_username=karl_goetz”

Forums

Using pydiscuourse (installed from pip), has also failed. Some examples of me finding with the options:

discourse_client.set_preference(mailing_list_mode=False, email_digests=True, email_direct=True, email_in_reply_to=True, email_private_messages=True, digest_after_minutes=1440, include_tl0_in_digests=True)

discourse_client.set_preference(‘karl_goetz’, email_always=True, mailing_list_mode=False, email_digests=True, email_direct=True, email_in_reply_to=False, email_private_messages=True, email_previous_replies=1, digest_after_minutes=1440, include_tl0_in_digests=True)

I can change my user preferences via chrome at example.com/u/karl_goetz/preferences/emails so that bit works and if nothing else I’ll try pushing data in through that route.

2

You will need to send a PUT request to /u/{{username}}.json

email_always:true
mailing_list_mode:false
mailing_list_mode_frequency:1
email_digests:true
email_direct:true
email_in_reply_to:true
email_private_messages:true
email_previous_replies:2
digest_after_minutes:10080
include_tl0_in_digests:false
3

Thanks @blake, I think that has me back on the right path.

curl -X PUT “https://discuss.example.com/u/karl_goetz.json?api_key=[...]&api_username=karl_goetz&mailing_list_mode=false&email_digests=true”

Now when I refresh the web my settings have changed from mailing list mode to activity summary.

After more annoyance and reporting to reading the pydisuourse source it appears the _PUT method doesn’t support passing params so I used their _request method directly.

d
{‘email_always’: ‘true’, ‘mailing_list_mode_frequency’: 1, ‘email_private_messages’: ‘true’, ‘email_direct’: ‘true’, ‘mailing_list_mode’: ‘false’, ‘digest_after_minutes’: 1440, ‘email_digests’: ‘true’, ‘include_tl0_in_digests’: False, ‘email_in_reply_to’: ‘true’, ‘email_previous_replies’: 1, ‘api_username’: ‘karl_goetz’, ‘api_key’: ‘[…]’}
discourse_client._request(‘PUT’, ‘/u/karl_goetz.json’, params=d)

Which behaved as expected.

Thanks again for your assistance.

PS.
Do you know why some user settings are only accessible via /u/username not /users/username ?

4

At some point we renamed the /users endpoint to /u so that we can have pretty short urls in the browser like we do for topics and categories. If you do

$ rake routes | grep username

you will see most of the routes and I think currently most of the /users ones have duplicate /u routes. The line is generating the /u routes:

but I believe there are still some /users routes that don’t have a matching /u route.

5

We should figure out what those are, and fix them so the /u works as expected..