What's New: Free Tier, Broadcast Send, and Full Mailbox Control

2026-04-02

Several features shipped this week that are worth a closer look. Here's what changed and why it matters.

Free tier - no credit card required

The most-asked question since launch has been: "Can I try this without a card?" Now the answer is yes.

New accounts can activate a permanent free plan with 100 emails per month, 50 per day, and 20 per hour. No trial clock, no credit card, no expiration. If you need more, paid plans start at $9.99/month.

To activate from an existing trial account, call:

POST /v1/billing/activate-free
Authorization: Bearer <your-token>

Or click "Start for free" on the billing page in the portal. The free plan is a real plan - not a degraded mode. Your mailbox works, policy enforcement runs, and decision traces are stored. The only limits are volume and a 14-day retention window.

If you're building an agent that sends low-volume transactional email - onboarding, receipts, alerts - the free tier covers it. You get the full policy engine, inbound handling, and all the guardrails, just capped at 100 sends per month.

Broadcast send - lists that actually send

List management has been in Molted for a while. Broadcast send is what makes it useful.

When you call POST /v1/lists/:id/broadcasts, the API now iterates every active subscriber on that list and sends each one a policy-checked email. Each send goes through the full policy engine - rate limits, deduplication, suppression - so a single broadcast can't spike your volume or re-send to an address you've already contacted.

A few things worth noting:

Unsubscribe headers are automatic. Every broadcast message includes RFC 8058 List-Unsubscribe and List-Unsubscribe-Post headers. This is required for Gmail and Yahoo's bulk sender requirements and correct by default - you don't configure it.

Template variables are injected per recipient. Each send gets unsubscribeUrl, listName, subscriberEmail, and subscriberName available as template variables. Your content can reference {{subscriberName}} without you wiring anything up.

Dedupe keys are per-broadcast. The key pattern is list-{listId}-{sendId}-{contactEmail}, so re-sending a broadcast (due to a failure or a retry) won't double-deliver to subscribers who already got it.

500 subscriber limit per broadcast (for now). Sequential send is intentional - it keeps your hourly rate flat and predictable. Parallel batch send is on the roadmap.

This is useful for any agent that needs to reach a defined list: trial activation nudges, feature announcements to beta subscribers, or dunning sequences for a segment of your contacts.

Contact capture endpoint

If your agent collects email addresses - from a landing page, a form, a conversation - and then needs to enroll that contact in a list and optionally send a confirmation, there's now one call to do all three:

POST /v1/agent/capture
Authorization: Bearer <your-token>
Content-Type: application/json

{
  "email": "user@example.com",
  "listName": "waitlist",
  "confirmationTemplate": "welcome"
}

The endpoint upserts the contact, subscribes them to the named list (creating the list if it doesn't exist), and optionally triggers a confirmation email through your policy-checked mailbox. If the contact already exists and is already subscribed, the call is a no-op.

The confirmationTemplate field is optional. If you leave it out, the contact is captured and enrolled without any outbound. If you include it, the template is rendered and sent as a normal policy-checked send - same rate limits, same deduplication, same decision trace.

The CLI also ships a capture command for testing:

molted capture --email user@example.com --list waitlist

For agent use cases like waitlist signup flows or in-conversation lead capture, this replaces three separate API calls (create contact, subscribe, send) with one idempotent operation.

Mailbox management - delete, clone, pause, and more

Four mailbox management features landed this week that fill gaps in the portal experience.

Delete a mailbox

Mailboxes can now be deleted via the API or the portal's danger zone:

DELETE /v1/agent/mailboxes/:id
Authorization: Bearer <admin-scoped-token>

Deletion is a soft delete - the mailbox is marked deleted_at rather than dropped from the database. All threads belonging to the mailbox are trashed. The portal prompts you to type "delete" before confirming.

One guard worth knowing: you can't delete the last active mailbox on a tenant. The API returns a 400 if you try. This prevents accidentally locking yourself out.

Clone a mailbox

If you've spent time tuning a mailbox - setting autonomy levels, configuring safety thresholds, building inbox rules and folders - you can now duplicate that setup instead of rebuilding it from scratch:

POST /v1/mailboxes/:id/clone
Content-Type: application/json

{
  "address": "support-clone@yourdomain.com",
  "displayName": "Support Clone"
}

The clone copies autonomy level, humanizer config, HITL settings, folders, and inbox rules. If any rule has a "move to folder" action, the folder reference is remapped to the cloned folder automatically. Catch-all routing is never copied - one mailbox per domain can be catch-all, and that decision belongs to the new mailbox.

The portal adds a "Duplicate Mailbox" card in mailbox settings with a dialog that shows what will be copied before you confirm.

Pause and resume

There's now a toggle in the portal to pause a mailbox. A paused mailbox rejects all outbound sends with a mailbox_paused error. Inbound still works. The pause state is useful when you're reconfiguring policy, debugging a send issue, or want to hold outbound without deleting anything.

Change email address

Mailbox addresses can now be changed from the portal settings page. The change takes effect immediately for new sends. Existing threads retain their original headers, so replies to old messages still route correctly.

CLI improvements

Two smaller CLI updates shipped alongside these features.

molted threads reply now accepts --html and --subject flags. Previously you could only reply with plain text and the subject was fixed to "Re: original subject." These flags let you send HTML replies and override the subject line from the CLI.

The CLI was also fully migrated from cookie-based auth to the agent API. All CLI commands now use Bearer token auth through the agentic-mailbox service rather than the portal's session cookie endpoints. This means the CLI works correctly in automated environments and CI without a browser session.

What's coming

Parallel broadcast send (for lists over 500 subscribers) is next on the delivery side. On the mailbox side, per-mailbox webhooks are in progress - so you can subscribe individual mailboxes to specific events rather than routing everything through the tenant webhook.

If you're already using Molted and want to try broadcast send or the capture endpoint, both are live and documented in the API reference. If you're new here, the free tier is a reasonable place to start.

For background on how policy enforcement works across all of these features, The Policy Rules That Protect Your Sender Reputation covers the 20+ checks that run on every send.