How to Send and Receive Email in TypeScript with Webhooks

If your Node.js app needs to send a confirmation email and react when a customer replies, you can handle both tasks with a TypeScript SDK and webhook endpoint. This guide uses a support-ticket example, then shows how to verify delivery and inbound processing with Inbound.

Prerequisites and project setup

You need:

• A Node.js TypeScript project
• An Inbound account and API credentials
• A verified sending address
• A public HTTPS URL for local or deployed webhook testing

Install the SDK and a web framework:

npm install inbound express
npm install -D typescript tsx @types/express

Keep the API key in an environment variable:

INBOUND_API_KEY=your_api_key

An API key should be stored as a secret rather than committed to source control. This common secret-management practice is especially important for email APIs.

For a broader implementation comparison, see this guide to sending and receiving email with one API.

The deciding factor among cloud products is whether they support this exact workflow.

1. Send a transactional email with the TypeScript SDK

Create src/email.ts and initialize the client:

import Inbound from "inbound";

const inbound = new Inbound({
  apiKey: process.env.INBOUND_API_KEY!,
});

export async function sendTicketConfirmation(
  recipient: string,
  ticketId: string
) {
  return inbound.emails.send({
    from: "Support <[email protected]>",
    to: recipient,
    subject: `Ticket ${ticketId} received`,
    html: `
      <h1>Thanks for contacting support</h1>
      <p>Your ticket number is <strong>${ticketId}</strong>.</p>
      <p>Reply to this email to add more information.</p>
    `,
  });
}

Call the function after creating a ticket:

const result = await sendTicketConfirmation(
  "[email protected]",
  "TCK-1042"
);

console.log("Email request accepted:", result);

This is the core pattern for using an email API with a TypeScript SDK: provide the sender, recipient, subject, and content, then log the returned result for troubleshooting. If your app only needs outbound messages, this is enough to start. For combined inbound and outbound behavior, continue with the webhook.

You can also review tools in the email products category when deciding how email should fit into your application.

2. Receive replies with a Node.js webhook

Configure your inbound email route in Inbound so replies are forwarded to your public webhook URL. Then add an Express endpoint:

import express from "express";

const app = express();
app.use(express.json());

app.post("/webhooks/email", async (req, res) => {
  const event = req.body;

  if (event.type!== "email.received") {
    return res.sendStatus(204);
  }

  const message = event.data;

  console.log({
    from: message.from,
    subject: message.subject,
    text: message.text,
  });

  // Match message.threadId or recipient to your support ticket here.
  // Save the reply before performing slower processing.

  return res.sendStatus(200);
});

app.listen(3000, () => {
  console.log("Webhook server listening on port 3000");
});

The exact event fields depend on your configured payload. Log one test event, then update the mapping for your application. A webhook should acknowledge quickly and move expensive work to a queue or background process. Reliable webhook handling patterns can help prevent duplicate processing.

The webhooks products category is relevant when you need more event-driven capabilities.

3. Test the complete email loop

Run the server and expose it through your HTTPS development URL. Then complete this checklist:

• Send a test ticket confirmation.
• Confirm the recipient receives the message.
• Reply to the confirmation email.
• Confirm the webhook receives an email.received event.
• Verify the sender, subject, body, and ticket mapping.
• Return HTTP 200 only after the event is accepted.

Common mistakes include using a private localhost URL, forgetting JSON parsing, exposing the API key in frontend code, and assuming every webhook event is a new message. Store an event ID when available so retries do not create duplicate ticket replies.