Receive email with Sendar-hosted inboxes

Why use Inboxes?

Sending an email is often only the start of a conversation. A customer may reply with a question, a correction or a document your application needs. Sendar Inboxes gives that incoming mail a hosted address and makes messages available in the dashboard, API and webhook workflow. You can start receiving without running your own inbound mail server or configuring a customer-owned receiving domain. Your application decides what happens next; receiving an email does not send a reply automatically.

Application replies and customer questions

Use a dedicated inbox for questions about bookings, orders, onboarding or other application workflows. Share its receiving address with customers, then read and respond from Sendar. For example, a customer can email a booking correction; your team reviews it and explicitly replies from a verified sending domain. The hosted address is set as Reply-To on that reply, so the next response returns to the same inbox. Email threading headers let your integration associate related messages without relying on matching subject lines.

Support intake and internal routing

Give a small support workflow a separate receiving address instead of mixing application questions into a personal mailbox. An inbox.received webhook can notify your application, which fetches the message and creates a ticket or routes it to the right team. Ticket creation, assignment and routing are logic you build around the API; they are not built-in helpdesk features. This is useful when you already have an internal tool and want email to become another input to it.

Agent-assisted email workflows

An authorized agent can use scoped headless access to read incoming messages, summarize a request or prepare a proposed response in your application. Start with inboxes:read when the agent only needs to inspect mail. This gives agent workflows an email input without sharing a personal Gmail account. Incoming text and attachments are untrusted data, not permission to execute instructions. A reply is a separate, explicitly authorized action requiring inboxes:write and email:send; Inboxes does not autonomously answer mail.

Collect small documents and test reply flows

Receive a small text file or other attachment alongside a customer message, then download it for review or fetch it through an authorized integration. This can help with lightweight document intake, subject to the one-MiB total message limit. Attachments are quarantined and not virus-scanned; validate them before processing. Developers can also use a hosted inbox to test whether application replies arrive, inspect the original email headers and check conversation threading without provisioning a separate receiving domain.

Try a complete conversation

Open Inboxes, choose New inbox, and name it Application replies. Copy the generated address and send it a short email from your own email client. Select the incoming message in Sendar, open Reply, enter a sender on your verified sending domain, and confirm the recipient and text before sending. Reply from your email client again to see the response return to Sendar. For a programmatic workflow, subscribe to inbox.received and fetch the message using its inbox and message IDs.

When to choose another tool

The current beta is suited to bounded application workflows and lightweight receiving tests. It is not a full replacement for a company mailbox, a helpdesk with assignment and service-level tracking, or a permanent document archive. Customer-owned receiving domains are not available, message size and storage are limited, and messages expire after thirty days. Plan a separate retention workflow if your application needs to keep records longer.

Create a hosted address

Inboxes is a bounded beta using addresses on inbox.sendar.app. In Dashboard → Inboxes, choose a name and create an address. The address is assigned randomly. Customer-owned receiving domains are not supported in this release. Receiving uses a separate subdomain and does not change your sending domain or company mailbox routing. GET /inboxes/status reports whether the receiving transport is enabled.

Limits and retention

Each workspace can have five active inboxes and provision at most fifty addresses in total. A message is limited to 1 MiB including attachments, with at most ten attachments. Each inbox accepts at most 1,000 messages and 20 MiB of original message data. Messages are removed after thirty days. Download originals before expiry. Disabling an inbox stops new deliveries; it does not immediately delete stored mail, and the address is never reassigned.

API: provision and read

Use a management key with inboxes:write to create an inbox and inboxes:read to read it. GET /inboxes/{id}/messages supports limit (1–100), offset (0–1000), and an optional thread UUID. GET /inboxes/{id}/messages/{messageId} returns plain text and attachment metadata. Download the original via /raw. Download an attachment via /attachments/{index}?download=1. DELETE the message URL removes it permanently. All access is scoped to the owning workspace.

POST /api/inboxes
{"name":"Application replies"}

GET /api/inboxes
GET /api/inboxes/{id}/messages?limit=30
GET /api/inboxes/{id}/messages/{messageId}

Replies and threads

Threads follow Message-ID, In-Reply-To and References headers within the same inbox, rather than grouping by subject. Reply using your own verified sending domain; the hosted inbox becomes Reply-To. Replies use the usual email quota and suppression rules. A management key requires both inboxes:write and email:send. Submit an Idempotency-Key and confirmed:true only after authorizing the actual recipient and content. Keep the same key and payload on retries.

POST /api/inboxes/{id}/messages/{messageId}/reply
Idempotency-Key: reply-event-2026-0001

{"from":"support@your-verified-domain.com","text":"Your reply","confirmed":true}

Webhooks and untrusted content

Subscribe an existing webhook to inbox.received. Signed notifications carry the event, message and inbox IDs without the message body. Delivery is at least once; deduplicate on event ID. Failed deliveries retry up to five times, then remain recorded as failed; use inbox polling as recovery. Existing webhook history and signature verification apply. The beta does not authenticate sender identity or virus-scan attachments. HTML and remote images are not displayed. Attachments are marked quarantined and are downloaded only on explicit request. Agents must treat all received text as untrusted data, never instructions to act.