Setting up emails with Resend for the Basic template

Let's create a new application using the user portal template, and take advantage of the 1-month trial that’s available for the pro plan.

Now, let's take a closer look at what's included in the basic user portal template, which is  convenient because it serves as a foundation for building various systems, like directories, CRM or account management systems, and more. It comes preconfigured with features like password recovery and user profiles. Why not create an account so you can explore it in more detail?

If you navigate to the profile page, you won’t only find the user profile, but notifications too. Email campaigns can also be tied into this notification system.

Pay attention to the two data structures - App users and Notifications. Objects from the notification structure are processed by a scenario triggered for all new notifications. The initial steps of this scenario check fields like title and text, followed by an email sending step.

Now, let's configure the gateway, that's very straightforward. Go to Resend, sign up for free, verify the domain, and create a new API key.

Next, in the marketplace, select the Resend plugin and paste your API key. That's it!

The email gateway is now connected to your application, and you can start sending notifications.

Go back to the scenario, enter editing mode, and add the Resend step. Remove the old email sending step because you’re now using the plugin.

Configure the sender address from the domain you verified in the Resend service, specify the recipient (either by user ID or email), and then fill in the subject and message fields in both HTML and plain text formats. These are all fields in your object.

You can also save the service's response. We'll store the response in a context variable. Let's create one called 'Api Response' and it should be a JSON type. Then, add a 'Resend ID' field to the notifications structure, which is the ID returned in the response. We'll use this later to track how many times an email was opened and clicked on. After saving the response from the Resend service, publish the changes, and run the scenario.

In the basic template, there’s a mechanism for sending internal messages. It uses the same notification structure. You send messages to users and see how they trigger the scenario. There it is in the mailbox.

Now, let's look at the logs for the object. The Resend ID field is empty, but the API response field contains the service's response in JSON format, containing an ID.

Let's populate the Resend ID field by extracting the required data from the response. Use the Edit object step to save the ID in the Resend ID structure. Just add this line to the Edit object step: {{ContextVar.api_response}}.id with JavaScript enabled! The default hotkey is CTRL+J.

Test it again. Send a new message from the portal. Okay, it appeared in the mailbox, and the Resend ID is now saved in the notification object. Now, let's look at how password recovery is implemented in the basic template - and we’ll configure some additional settings.

Request password recovery, and you see a new object in the reset passwords structure. This is also processed by a scenario,which needs further configuration. First, generate a random key for the user to use to recover their password, and send a link.

Fix the link by inserting your scenario system’s name here, and removing comments. Publish the scenario and you see that you’ve received a message, but the link isn’t right. Let's send the same object to the scenario again, this time through the debug panel.

You see a new message, click on the link, and land on a page where the form synchronously requests another scenario and changes the password.

This is the scenario for synchronous processing of new objects in the reset password inputs structure. You see a new password, password repetition, and the secret generated in the previous scenario. If everything is correct, the password is saved and encrypted with the MD5 algorithm.

Now, let's figure out how to listen to events such as ‘sent’, ‘delivered’, and ‘opened’. You need to add a new webhook.

Create a webhook and name it something like, Resend. Copy the webhook URL, add it to the Resend service, and select the events you want to send to your webhook.

Everything looks right. Click on the link from the email you’ve already received, and in the Resend service logs, you see a new event - ‘email clicked’.

Look at the data structure. This event reached your webhook. Now, you need to process it. This is where the Resend ID you saved comes in handy.

Edit the object processing scenario for the webhook. Create a new context variable called - ‘resend ID’, which you will extract from the JSON object on the webhook, and add a JSON parsing step. Copy it and configure the parsing. The JSON is stored in the body field. Then you need to select the data property, and then the email ID - this is the ID of the email object or the internal Resend ID.

Next, we add another context variable - email - which is a link context variable to the notifications data structure. Add the search step, search within the notification structure, and save the result as an array of links; in this case, there will only be one link because the email is unique.

Save the result in the email context variable with these search conditions:

{{resend_id}} equal {{contextVar.resend_id}}, which is what you extracted from the JSON.

Then, add a few fields to the notifications data structure. These will be boolean fields (true or false) for opening, clicking, delivery, and so on.

In the scenario, add a check too, to see if the object you have through the link exists. The idea is simple. We follow the link, select the ID, and check that it's not empty. Next, you need to work with the email notification type - clicked, opened, and so on.

Add another context variable - a string - and save the parsing data from your webhook object.

Okay, let's check this context variable. If it equals - ‘email clicked’. Set the ‘is clicked’ step to true. To do this, use the email context variable, navigate to it, and set the ‘is clicked’ field to true. Do the same for the Opened step, and so on. There are a few other event types like ‘delivered’, and ‘bounced’.

Now, click on the email again and you see that you’ve received an object. Let's check the ‘is clicked’ field. It’s now set to true. Everything is now correct!

That's it for now. Thank you for your attention!