DEV Community: Roshan Jonnalagadda

Sendmux CLI: email inbox API in your terminal

Roshan Jonnalagadda — Thu, 18 Jun 2026 10:10:54 +0000

A lot of agent email testing starts with the same awkward loop: send a message, refresh a dashboard, copy JSON, then guess what your agent will see.

Sendmux CLI cuts that loop down to the terminal.

It gives developers and AI agents direct access to Sendmux: an email inbox API for AI agents and SaaS platforms. You can create and manage mailboxes, search inbound mail, send email, inspect API responses, and script the same workflows your app or agent will run later.

If your AI agent needs to receive email, triage messages, search an inbox, reply to a thread, or send outbound mail through a controlled email sending API, the CLI is the fastest way to prove the flow.

What Sendmux does

Sendmux gives software and AI agents a proper email layer.

Instead of stitching together a sending provider, IMAP access, inbound parsing, webhooks, API keys, mailbox storage, and agent tooling by hand, Sendmux puts those surfaces behind one API platform.

The complete email API platform includes the following:

Email Inbox API for receiving, searching, reading, and managing agent inboxes
Sending API for outbound email from a mailbox
Management API for teams, domains, mailboxes, API keys, routing, and platform controls
SDKs for TypeScript, Python, Go, PHP, and Ruby
MCP for authorised AI agent access
CLI for terminal workflows, scripts, debugging, and automation

That means Sendmux can act as an email inbox API, inbound email API, email sending API, SMTP API, and agent mailbox layer from one system.

Why the CLI exists

Email infrastructure gets painful when the first question is, "Where do I test this?"

With Sendmux CLI, the terminal becomes the control surface.

You can list mailboxes, inspect messages, search snippets, send test emails, and verify API behaviour in the same environment where your agent, scripts, or CI jobs already run.

Here's why that matters:

You can test an agent inbox before wiring it into an app
You can search inbound email without building a UI
You can send a controlled outbound email from a mailbox
You can debug API responses with machine-readable JSON
You can manage Sendmux resources in scripts
You can validate scoped API keys before handing them to an agent
You can prototype email workflows before moving them into an SDK

Install

brew install sendmux/tap/sendmux

or:

npm install -g @sendmux/cli

Then configure local profiles so you do not pass keys on every command:

sendmux profiles:set management --api-key smx_root_...
sendmux profiles:set mailbox --api-key smx_mbx_...

Management commands use smx_root_ keys. Mailbox and sending commands use smx_mbx_ keys.

The CLI checks key prefixes before making the API call, so the wrong key type fails early instead of hitting the network.

Three workflows that show the shape of it

1. List agent mailboxes

A platform or agent operator can list the mailboxes available in a Sendmux workspace.

This helps before assigning inboxes to agents, checking mailbox provisioning, or confirming a management key can see the expected resources.

2. Search inbound email

Agents need more than raw email delivery. They need searchable, structured access to messages.

With the Email Inbox API through the CLI, you can search snippets in an agent inbox and return clean JSON for another process to read.

The result:

Find the latest invoice email
Search unread support messages
Pull matching messages into a triage script
Check whether an external service sent a verification email

3. Send outbound mail

Sendmux also handles outbound email.

From the CLI, you can send through the Sending API using a mailbox-scoped key. You can include idempotency keys for safer retries and use JSON output when another tool needs to process the result.

This fits agent replies, transactional email tests, workflow notifications, and scripted operational mail.

Built for humans and agents

The CLI is designed for developers at a terminal and agents that need predictable output.

By default, API commands print readable JSON. Add --json when you need machine-readable output for scripts, agent tools, or automation.

The CLI also supports practical API flags:

--body for inline JSON request bodies
--body-file for request payloads from disk
--query for query parameters
--path for path parameters
--header for extra headers
--idempotency-key for safer send retries
--if-match and --if-none-match where supported by the API operation

The command set is generated from Sendmux public API surfaces. The current CLI includes 95 generated API operation commands: 40 Mailbox commands, 52 Management commands, and 3 Sending commands.

Where CLI fits beside MCP and SDKs

Sendmux gives you a few ways to work, depending on where the task lives.

Use MCP when an AI agent should call authorised Sendmux tools directly. Sendmux has Documentation MCP for searching docs and Product MCP for authorised Management, Mailbox, and Sending tools.

Use SDKs when you are building application code. Sendmux SDKs are available for TypeScript, Python, Go, PHP, and Ruby.

Use CLI when you want terminal control: one-off checks, local testing, scripts, CI jobs, debugging, and agent-friendly JSON workflows.

A simple way to choose:

MCP is for agent tool access
SDKs are for application code
CLI is for terminal workflows
APIs are the underlying contract

Why this matters for AI agents

AI agents increasingly need to deal with real-world systems that still use email.

Verification emails. Invoices. Support threads. Customer replies. Vendor notices. Billing alerts. Operational messages.

A normal inbox is built for a human with a mouse. An AI agent needs an API.

Sendmux gives agents a programmable inbox, outbound email, webhooks, Server-Sent Events for mailbox updates, scoped API keys, MCP tools, and SDKs. The CLI gives developers the quickest way to inspect and prove those workflows before shipping them.

Try it

Install the CLI, create a mailbox-scoped key, and run a small workflow:

List a mailbox
Search for a message
Send a test email
Repeat the same flow from an SDK or MCP-enabled agent

That is the point of Sendmux CLI: email infrastructure you can see, test, script, and hand to agents without leaving the terminal.

We Built a Feedback Widget That Ships Submissions Straight to Your Inbox

Roshan Jonnalagadda — Tue, 26 May 2026 04:14:50 +0000

Most feedback widgets are dead ends. A user fills out a form, hits submit, and the data lands in a dashboard no one checks. Two weeks later someone remembers to log in, scrolls through 47 entries, and gives up.

Sendmux Feedback Widget is a drop-in Web Component that turns website and in-app feedback into structured JSON you can route to a webhook or an inbox. It is built for teams who want user input to trigger work instead of sitting in a database.

Here is how it works.

What does the widget do?

It is a single custom element called . Drop it into React, Vue, Svelte, or plain HTML. It renders a floating button and a modal for collecting feedback. The user picks a category, writes a message, and hits send. Your server receives clean JSON with the message, page URL, category, and any user context you pass in.

One line to install:

pnpm add @sendmux/feedback-widget

One line to use:

<sendmux-feedback
  endpoint="/api/feedback"
  position="bottom-right"
></sendmux-feedback>

Zero framework dependencies. Shadow DOM styles so it won't fight your site's CSS. SSR-safe import for Next.js or Nuxt.

Why email-first?

Here is the thing: email is the universal API every team already knows how to read. Support tools, agent frameworks, and automation platforms can all consume an inbox. So instead of building yet another dashboard, we made the widget deliver structured data to a webhook or a secure relay that turns it into email. From there your agents can classify it, group duplicates by URL or user, summarise threads, or open GitHub issues automatically.

The widget itself does not ship the agent. It ships the collection layer and the payload contract. You build the workflow on top.

What about accessibility?

The modal traps focus, supports keyboard navigation, labels every control, and respects prefers-reduced-motion. Dark mode is automatic if your site already sets it. The component uses system fonts by default but accepts a Google Font if your brand requires one.

Too many open-source UI components ship with accessibility as an afterthought. We treated it as a requirement from the first commit.

A quick look at the payload

When a user submits feedback, your endpoint receives this:

{
  "category": "bug",
  "message": "The export button does nothing on mobile",
  "url": "https://mysite.com/dashboard",
  "user": {
    "id": "user_123",
    "email": "customer@example.com"
  },
  "metadata": {
    "plan": "pro",
    "account_id": "acct_456"
  }
}

You can pass user context and metadata from your app without exposing secrets in the DOM. The widget reads from a global config object if you prefer that over HTML attributes.

Who is this for?

If you run a SaaS product and you want user feedback to trigger actual work, this is for you. If you are building agent workflows that consume email as input, this gives you a frontend collection layer that outputs exactly the structured data you need.

If you just want a free alternative to Canny or UserVoice without the overhead, this also works.

Where to get it

The repo is open-source on GitHub: https://github.com/Sendmux/website-feedback-widget

We ship a package install today. A CDN bundle via unpkg is coming after the next release. Documentation and a live demo are in the README.

If you try it, open an issue or start a discussion. We are actively using this as the collection layer for Sendmux itself, so it will keep improving.

What would you hook a feedback widget up to? A support queue? A GitHub Action? Something we have not thought of yet? I would genuinely like to know.