Manage smtp servers via REST api

[aqp696]

Is your feature request related to a problem? Please describe. I would like to register a new SMTP server via the REST api. Describe the solution you'd like Currently there are 8 sections in the settings area (General, Performance, Privacy, Media uploads, SMTP, bounces, messengers and appearance). The more generic approach would be to have a root api endpoint for settings in /api/settings. Nested to it the 8 sections:

section	endpoint
General	/api/settings/general
Performance	/api/settings/performance
Privacy	/api/settings/privacy
Media uploads	/api/settings/media
SMTP	/api/settings/smtp
Bounces	/api/settings/bounces
Messengers	/api/settings/general
Appearance	/api/settings/appearance

This is the general idea. In particular for the case of SMTP:

Method	Endpoint	Description
GET	/api/settings/smtp	List all smtp servers.
GET	/api/settings/smtp/:id	Gets a single smtp server.
GET	/api/settings/smtp/lists/:id	Gets smtp servers in a list.
POST	/api/settings/smtp	Creates a new smtp server.
PUT	/api/settings/smtp/:id	Updates a smtp server by id.
DELETE	/api/settings/smtp/:id	Deletes a single smtp server.
DELETE	/api/settings/smtp	Deletes one or more smtp servers.

[knadh]

Hi @aqp696. Splitting the API into multiple sections makes sense. That also directly reflects how settings are organised on the UI.

Adding additional logic and endpoints for blocks inside certain sections, I'm not sure if it is warranted. That may lead to the rabbi thole of adding granular logic for many different settings and sections. Settings rarely change, so I think it's a fair tradeoff to not have the complexity of adding APIs for per-setting-blocks (eg: SMTP, messenger).

[aqp696]

Hi @aqp696. Splitting the API into section makes sense. That also directly reflects how settings are organised on the UI.

Adding additional logic and endpoints for blocks inside certain sections, I'm not sure if it is warranted. That may lead to the rabbi thole of adding granular logic for many different settings and sections. Settings rarely change, so I think it's a fair tradeoff to not have the complexity of adding APIs for per-setting-blocks (eg: SMTP, messenger).

I understand @knadh . Let me explain my particular use case :smile:.

I have a SaaS and I want a feature that for every new customer that configures smtp credentials can deliver bulk emails to it's users.

The solution I thought was to use Listmonk using it's api. I wan't to provision in listmonk a new smtp server dynamically without the manual intervention of a listmonk user via the GUI (this option is not viable in order to scale horizontally the saas). I think that it would be very useful my proposal.

[knadh]

Are you planning to use a single listmonk instance for multiple customers? That would be very risky.

On the other hand, if it's one listmonk instance per customer, you should be able to make-do with the current settings API (get first, add SMTP, post) until a per-section API is available.

[aqp696]

We are planning to have only a service of listmonk in the cluster. And we could scale a dockerized listmonk with more replicas if needed. But only a listmonk with multiple smtp servers configured.

[ChrisTG742]

@aqp696: If you're in a hurry with that you can yet do this by exporting/importing the respective database (table "settings"):

select * from settings where key = 'smtp'; gives you a JSON-like object that contains all the settings. Maybe you can use this as a temporary solution.

[knadh]

I attempted this, but this isn't straight forward. This involves splitting up https://github.com/knadh/listmonk/blob/master/models/settings.go#L4 this into multiple strucuts and adding conditional logic for each section explicitly in get and update functions. Overly complicated for a niche usecase. While the current get all, put all is clunky, it's still works, and externally orchestrating granular settings updates is a rare. Closing this for now. Thanks!