Should an API service send the user activation email or the client application?

Question

I'm trying to develop a REST API web service. I have a question about how to handle user activation email. Currently, the API service handles email sending.

Here is the flow I have at the moment:

1. User registers via the client application
2. Client application POSTs to API service
3. API service validates and adds the user to the database
4. API service sends the User an activation link
5. User clicks on the activation link, which will take them to the client application activation page
6. Client application activation page POSTs to API service
7. Done

Here is where I currently see the issue:

Because the API service is currently sending the email, the client application does not have control over the look and feel of the email. And there may be URLs in the email that should point to the client application.

---

Another option is instead of the API service sending the activation email, it will return the activation key to the client application. The client application will then be able to send the activation email to the user.

Two issues I see with this strategy:

• Security, as the activation key is now exposed to the client application.
• Not DRY, as each client could be responsible for email sending.

What do you think is best way to handle this?

I would like to allow the client application to customize their email, as well as include client-specific URLs (activation page).

Answer 1

TL;DR

Create a small service for developers to create templates, let them declare which template they want to use when POSTing to your activation API

---

Summary of the problem:

• e-mail needs to look different for every client app
• sending mail should be implemented once
• solution should be secure

There is no need for the e-mail to look different every time. So there's no need to send the e-mail format with the POST request.

Instead one of the following can be done:

1 Create a separate API endpoint to define templates and let the client app choose one of them when POSTing the request for activation.

This is not exactly secure, at least poses a challenge to make it safe if you want to accept HTML from the client apps.

Recommended solution:

2 Create a tool for developers (in the same website where they get their API key) that accepts templates and aids creating them. Client app can choose one of them when POSTing the request for activation. Fragment of the request body being something like:

...
"template": "foobar-app",
"fields": {
    "title": "Welcome to foobar app",
    "username": "jim78"
}
...

No HTML in the fields allowed.

This lets you have pre-defined templates prepared by the developer that can be used by your e-mail sending service and no bug in client app can cause the e-mail to become unsafe. Also, you get a place where the templates can be worked on and tested. (the developer can send them to himself to debug - making e-mail templates is horrible, belive me)

You'll be able to support your developers/clients better in the future and prepare a set of working templates tested in multiple mail clients.