# Send a Personal Welcome Email for Each Signup Through an API

Yes. Your backend starts one run per signup; the agent reads the company's site and sends a short personal welcome through your Resend account.

[Run this on Rush](https://cloud.getrush.ai/run/welcome-email-per-signup/resend/).

## What the agent does

Your backend starts one run when a user signs up, with their name, email and company domain after the prompt. There is no repository: the run uses its browser to read the company's website, and the Resend connection to send the email. Resend's MCP server, connected once with OAuth, gives the agent the account's emails, domains, contacts, templates and logs.

The agent reads the signup's company site first: the home page, the product or about page, and anything that says what the company does and who it sells to. It picks one specific, true detail to mention, such as the product they sell or the stack they build on, and one next step in your product that fits what it read. If the site does not load or says too little, it writes a plain welcome without a company detail rather than inventing one.

Before it sends, it reads the Resend account to send the way you already do. It lists the account's domains and uses a verified one for the from address, so the email does not fail on an unverified sender. It reads the recent sent emails in the logs to match the length, greeting and sign-off your team already uses, and keeps the body under 100 words as the prompt asks.

Then it sends one email through Resend to the signup's address and returns what it sent: the `subject`, the `body` and the Resend email id. It sends to that address only, sends once, and adds nothing to an audience or broadcast.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A user signed up; their name, email and company domain follow this prompt. Read the company's website with the browser, then send one welcome email under 100 words through Resend, from a verified domain on the account, that mentions one true and relevant thing about their company and one next step in the product. Match the tone of recent sent emails in the Resend logs. If the website says too little, write a plain welcome with no company detail. Send to that address only, once. Return JSON with subject, body and the Resend email id."
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is the agent's final answer, a JSON object with `subject`, `body` and the Resend email id, and the email itself in the signup's inbox. Your backend receives the object as `data.result` in the `run.completed` webhook and can store it on the user's record, so support can see what the new user was sent.

The Resend email id ties the run to Resend's own record of the delivery, so a bounce or a complaint on that message can be traced back to the run that sent it. Before turning this on for every signup, read a sample of results against the company sites they cite and check the detail is accurate and the next step makes sense.

The session keeps every page the browser opened and every Resend call the agent made, so for any email you can see what the agent read before it wrote. A run that failed to send ends `run.failed`, and your webhook hears that too.

## Run it on every new signup

Your signup handler calls `POST /o/{org}/sessions` once per new user, with their name, email and company domain added to `input`. Send the user's id as the `Idempotency-Key`, so a retried signup event returns the run already started instead of sending a second welcome.

Set a webhook on the API key and your backend receives each result when its run finishes, with no polling. A key runs at most `max_concurrent` sessions at a time, 4 by default, and starting one more answers `429`, so queue signups in your backend and start the next run when one finishes.

## Why run it on Rush?

A personal welcome needs someone to read each new user's company site and write two lines about it, which stops happening once signups pass a handful a day. A Rush run does both for every signup in its own sandbox with a browser, and sends through the Resend account and domain you already use.

Each email comes with its record: the pages read, the Resend calls made and the email id. That is what makes it safe to automate a message that goes to a real person under your name, because any email can be checked against what the agent saw.

## Frequently asked questions

### How does the run get access to Resend?

Connect Resend's MCP server once with `POST /me/connections`, `"type": "mcp"`, the server URL and `"auth": {"mode": "oauth"}`, then open the `authorize_url` while signed in to the console. A key run gets only the connections it names, so name it in `connections` on the run, or save an agent that names it and run that agent.

### Could it email someone other than the new user?

The prompt limits it to one email to the signup's address. The session records every Resend call, so you can check that each run sent exactly one email to the right person.

### What if the company website is empty or blocks the browser?

The prompt tells the agent to send a plain welcome with no company detail, so it does not make one up. The session shows which pages it tried to open and what they returned.

### Does this need a repository or GitHub?

No. A run with no repository in `resources` needs no GitHub App. The run uses its browser and the Resend connection only.

### Can I review emails before they go out?

Yes. Change the prompt to return the subject and body without sending, review them in your backend, and send the approved ones as a follow-up message to the same session asking it to send.
