Why a Mailera mailbox goes to sleep—and how to wake it

Why does a mailbox go to sleep?

A mailbox you haven’t been using can go to sleep in Mailera. Background checks run more often for mailboxes in active use and less often for idle ones. Inactive mailboxes can sleep and wake on use.

Mailbox sleep is Mailera’s inactivity behavior, not another name for an authentication error. For an explicit wake action, use POST /mailboxes/{id}/sync rather than relying on an app visit or a message read to change its state.

Mailera connects your existing mailboxes; it doesn’t create new mailboxes or email addresses. For the wider workflow across connected accounts, see unified inbox operations for AI agents.

Is the mailbox sleeping, paused, or disconnected?

Request GET /mailboxes/{id} and inspect data.status, data.sync, data.error_code, and data.error. An old timestamp is a reason to investigate, not enough by itself to diagnose sleep.

Read those fields together. The data.sync object includes state, level, last_synced_at, next_sync_at, and sleeping_since.

The sign-in status endpoint checks Microsoft directly. For other providers, it uses the latest sync result. Keep that difference in mind when interpreting a status response alongside an old sync timestamp.

Pause/resume and wake-up are separate operations. Don’t use a sync request as a substitute for explicitly resuming a manually paused mailbox.

Is this the same as IMAP IDLE?

No. RFC 2177 defines IMAP IDLE as a command that lets a client accept unsolicited mailbox updates from a server. Mailera mailbox sleep concerns inactivity in Mailera. Disabling IMAP IDLE is not the wake-up procedure described here.

How do you wake a sleeping mailbox and check the result?

Use a mailbox you own or administer. Keep the API key in the environment variable $MAILERA_API_KEY, and put the target mailbox ID in $MAILBOX_ID. The examples use the base URL documented in the Mailera API reference.

1. Prepare a narrowly scoped key

In Settings, open the API key tab and choose Create key. Set Mailbox scope to the group containing the affected mailbox. Select Read and Sync for this workflow.

read lets you inspect mailbox details and messages. sync permits the wake request. You don’t need Send messages or Manage mailboxes just to wake and inspect a sleeping mailbox.

Copy the key when Key created — copy it now appears. Keep it out of screenshots, source files, and shared logs.

2. Identify the mailbox and record its current state

List the mailboxes available to the key:

curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes" \
  -H "Authorization: Bearer $MAILERA_API_KEY"

Match the intended mailbox in data and use its id as $MAILBOX_ID. Don’t simply select the first result in a workspace with several mailboxes.

Read its details before requesting sync:

curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID" \
  -H "Authorization: Bearer $MAILERA_API_KEY"

Note the current sync values and any error information. These give you a baseline for the next check.

3. Request sync

The sync operation also wakes sleeping mailboxes and requires the sync scope:

curl --silent --show-error -X POST \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/sync" \
  -H "Authorization: Bearer $MAILERA_API_KEY"

For an MCP workflow, the corresponding tool is sync_mailbox, also requiring sync. The developer overview covers Mailera’s REST and MCP interfaces.

4. Check state and actual messages

Run the mailbox-details request again. Compare the sync information with your baseline and inspect any errors. Then list up to 10 Inbox messages.

curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=10" \
  -H "Authorization: Bearer $MAILERA_API_KEY"

Choose a recent message visible in the provider’s Inbox and look for the corresponding result in Mailera. Compare subject, from, and received_at; check folder too. A message in another folder won’t be included in this Inbox-only request.

Keep two checks separate: whether the mailbox’s sync information has changed, and whether the message you need is present. A changed timestamp alone doesn’t establish that every expected message is available.

5. Investigate sign-in if messages remain missing

curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/status" \
  -H "Authorization: Bearer $MAILERA_API_KEY"

If the result points to a sign-in problem, or the mailbox still isn’t updating, continue with the sync troubleshooting guide. Don’t keep treating every missing-message case as sleep.

What happens to messages and automation?

Keep mailbox sleep separate from message retention. Mailera’s free self-serve workspace has a 30-day message-retention period. That number describes retention, not the mailbox’s inactivity timer.

On initial connection, Mailera loads messages within the retention period, newest first. Use a recent message for your recovery check rather than making an old message the sole test. Don’t assume that waking a mailbox will recover its complete history.

For a missing message, compare Mailera’s synchronized view with the provider mailbox directly. An absent result in Mailera is not enough to determine what is stored at the provider.

For Microsoft mailboxes, Mailera receives new mail through Microsoft Graph change notifications, with periodic background checks as a fallback. Microsoft’s Outlook notification documentation explains how subscriptions specify the changes to monitor and the endpoint that receives notifications.

For an automation waiting on mail, make the next action depend on finding the expected message, not merely issuing the wake request.

What mistakes commonly prevent recovery?

• Using a read-only key. Reading mailbox state requires read; waking it requires sync. Check the key’s permissions and mailbox-group access.
• Diagnosing sleep from one old timestamp. Inspect the full mailbox state and errors before choosing a remedy.
• Confusing pause with sleep. Use the separate resume operation for a manual pause. Don’t add manage permission to every wake-up key just in case.
• Stopping after the sync request. Verify that the expected message appears in the right folder.
• Repeating sync without inspecting the result. Read mailbox details and sign-in status before deciding what to do next.

How should an AI agent handle wake-up safely?

Give the agent only read and sync, restricted to the mailbox group it needs. Wake-up does not require sending permission.

Treat incoming message bodies as untrusted data, not instructions. An email must not direct the agent to change credentials, broaden permissions, or send information to a new destination. If a separate workflow enables sending, require confirmation before it sends.

The Mailera security overview and unified inbox operations guide provide the broader context for controlling agent access.