An inbound.new alternative with templates and campaigns built in.

What each one ships.

Moving from inbound.new.

1. 01

   Add your domain and publish the DKIM and SPF records Samva generates next to the old provider's. Both can send while you switch.

2. 02

   Swap the send call.

   import { Inbound } from "inboundemail";
   
   const inbound = new Inbound(process.env.INBOUND_API_KEY!);
   
   const { data, error } = await inbound.emails.send({
     from: "Your Name <you@yourdomain.com>",
     to: "ada@example.com",
     subject: "Your receipt",
     html: "<p>Thanks for your order.</p>",
   });
   

   await samva.messages.send({
     from: { email: "orders@example.com" },
     to: [{ email: "ada@example.com" }],
     channel: "email",
     email: {
       subject: "Your receipt",
       html: "<p>Thanks for your order.</p>",
     },
   });

3. 03

   Map webhooks. Samva sends signed events for sent, delivered, bounced, complained, failed, and received, with received going to the endpoint your domain's receiving route names. Opens and clicks arrive as message.opened and message.clicked, and unsubscribes as contact.unsubscribed.

   inbound.new event	Samva event
   email.received	message.received

4. 04

   Recreate templates as versioned templates, or send your existing HTML inline while you move.

5. 05

   Keep the old provider's suppression list in your app and filter against it. Samva cannot import it.

6. 06

   Turn on receiving if you want replies back.

What does not move: templates, the suppression list, and message history.