Email rendering & delivery via API / HTTP

[joshbalfour]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Network project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe your problem

Hiya,
First off: huge fan of what the team has accomplished here, this is by no means a criticism just a feature idea 😄

I've been setting up email templates (did SMS first) and was thinking:
Would it be more in the project ethos of "API-only - without templating or theming headaches" to have email/SMS be processed via a user-built API rather than rendered via the templating system and sent via SMTP?
I got to this by running through a requirement that's come up of being able to theme the emails depending on who it's sent to (we have centralised auth but will theme the login screens based on the product you're logging in to).

Describe your ideal solution

Much like the way you currently configure SMS delivery via the config, you could configure an endpoint that would be sent the message type (e.g. recovery.valid), the context variables (e.g. .RecoveryURL) and who to deliver it to.

Workarounds or alternatives

It's incredibly cursed but I could:

1. Change the templates to:
   body - render a JSON string with the context variables
   subject - the message type

2. Build an SMTP server that would take the to/subject/body from the email, parse the context from the body and message type from the subject

3. Render the new email body and subject based on the message type, context, and who it's going to, then send it on its way

If this feature was built then I could cut out the first two steps here so it'd be a lot less cursed.

Version

v0.10.1

Additional Context

No response

[aeneasr]

Josh, I think this is a great idea! We will probably keep email rendering in for ease of use, but it could make sense to have an API-based courier. This has been requested also in issue #1030

I think it should be relatively straight forward, we can probably re-use the SMS courier as that already is based on a REST API.

[hugotiburtino]

joshbalfour, you read my thoughts! 😄

For our case I would also need more info from the UI that made the request in the first place (like the origin or in general all headers). If it were by default or we could customize it, it would be great.

By the way, if we could also customize to send the rendering back to kratos courier or just not (that means the API would send the email by itself) it would be even better.

[kmherrmann]

As this is being discussed in a couple of places, let's make this one the canonical one.

Also see #1030

PR: #3048