What's New: Journeys in the Portal and Automatic Warmup Scheduling

2026-04-21

Two features shipped this week. Here's what changed.

Journeys overview page in the portal

Journeys - multi-step email sequences that agents trigger and orchestrate - are now visible in the portal.

The journeys page shows every active journey with its step count, how many contacts are currently active across all steps, and total enrollment history. Clicking into a journey shows a per-step breakdown: how many contacts are currently at that step, plus a table of recent enrollments with timestamps and current status.

Journeys themselves are still defined and orchestrated through the API, CLI, or MCP - the portal is read-only for the journey structure. What's new is visibility into what's running.

Manual enrollment

The portal also adds a manual enrollment form. If you have a contact email address and want to enroll them into an active journey directly - without going through an API call - the form accepts an email address and posts the journey's trigger event on your behalf.

This is useful for testing ("let me enroll my own address and watch what happens") and for one-off enrollment decisions that don't need to be automated. Enrollment fires the same event that an agent would fire, so the contact goes through the same journey steps as any other enrollee.

Automatic warmup scheduling for over-limit sends

Domain warmup has a daily cap. When you're warming a new sending domain, you can only send a certain number of emails per day - exceeding it risks triggering spam filters before your domain has built enough reputation.

Previously, marketing sends that exceeded the warmup cap were blocked immediately with a warmup_limit status. The agent received a blocked response and had to decide what to do with it.

That behavior has changed. Marketing sends that exceed the warmup cap are now automatically deferred to the earliest future date with available warmup capacity.

The send response now looks like this for a deferred send:

{
  "requestId": "req_abc123",
  "status": "scheduled",
  "reason": "warmup_defer",
  "scheduledFor": "2026-04-22T00:00:00Z"
}

The email isn't dropped. It's queued for the next available warmup slot. The agent doesn't need to implement retry logic or manually reschedule - the infrastructure handles it.

A few important details:

Transactional sends are not deferred. Templates marked as transactional (type transactional, or IDs starting with _) still hard-reject with warmup_limit. Transactional email - password resets, receipts, account notifications - shouldn't be silently delayed. Only marketing sends are eligible for deferral.

There's a 30-day horizon cap. If the warmup schedule is so backed up that the earliest available slot is more than 30 days out, the send returns status: blocked, reason: warmup_horizon_exceeded with a projectedDate field. This prevents sends from being silently queued for an unreasonably long time.

You can cancel a deferred send. If you enqueued a send that's now scheduled for a future warmup slot and you want to cancel it:

DELETE /v1/agent/sends/:requestId
Authorization: Bearer mm_live_...

This releases both the queued job and the reserved warmup slot, so the capacity becomes available for other sends.

Simulate shows deferral before you commit. The simulate-send endpoint now returns wouldDefer: true and scheduledFor when a send would be deferred, so agents can preview the deferral behavior before executing the actual send:

{
  "wouldAllow": true,
  "wouldDefer": true,
  "scheduledFor": "2026-04-22T00:00:00Z",
  "simulation": true
}

The journeys portal page is live at /journeys in the portal. Warmup deferral is active immediately for all marketing sends that hit the daily warmup cap.

If you're managing a domain warmup and want to understand how the warmup limits interact with your sending volume, Rate Limiting and Cooldowns: Protecting Sender Reputation covers the full rate limiting model.

For questions or to get started, create a free account or check the docs.