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. Opens and clicks are in the dashboard and the API, not webhooks.

   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.