Email workflows often cross several surfaces. A developer creates a domain in a dashboard, a script sends messages, and replies arrive somewhere else. Sendar now brings three more parts of that workflow into the product: scoped headless management, a link checker, and Sendar-hosted receiving inboxes in beta.
Manage resources from your tools
The Headless page lets a workspace owner create a management key with explicit permissions. Grant domain reads to a diagnostic script, template writes to a deployment job, or inbox reads to an authorized application. Each key displays its permissions and can be revoked from the dashboard. The secret is shown once, so store it in your server's secret configuration.
These keys support REST access and a downloadable Node.js CLI. Compatible MCP clients can also discover management tools for the scopes they have received. The initial tools cover domain setup, verification, usage, template creation, webhook listing, link checks and inbox workflows. REST and the CLI cover additional update and deletion operations. This release does not promise that every dashboard action has an MCP equivalent.
Existing sending keys retain their previous permissions. Headless keys cannot create more credentials, change billing or access administration. Start with read access and add a write permission only when your integration requires it. Use a local preview before any live send, and keep the same idempotency key when investigating a retry.
Catch link mistakes before a broadcast
A placeholder or missing destination can undermine an otherwise useful message. The new Link checker accepts rendered HTML and returns a queued check. It distinguishes broken links from destinations that cannot be checked reliably, and from action links that it deliberately skips.
The checker is also available in the template editor and broadcast composer. Draft templates remain editable. The broadcast interface checks its current rendered sample before enabling send; if you change that content, check it again. An intentional broken link needs an explicit override reason associated with that exact content.
Checks use bounded HEAD requests and do not load page bodies. Recognized password-reset, verification and unsubscribe links are skipped, and private network destinations are blocked. A successful response is evidence about that destination at check time, not a promise about every personalized email. Review skipped and inconclusive results yourself. Each job checks at most forty anchors, with thirty jobs per workspace per day.
Give application replies a home
The Inboxes beta assigns random receiving addresses on a dedicated Sendar subdomain. Create an inbox, give its address to the application workflow you control, and read incoming messages in the dashboard or API. Messages are grouped using email threading headers rather than subject lines. Retried delivery of the same message is deduplicated.
You can reply using a verified sending domain already connected to your workspace. Sendar sets the hosted address as Reply-To so the next response can return to the inbox. Replying requires an explicit send action and uses the ordinary sending quota and suppression rules. Receiving a message never authorizes an agent to answer it automatically.
Understand the beta boundaries
Each workspace has up to five active inboxes. Messages are limited to one MiB, with up to ten attachments, and each inbox holds up to one thousand messages or twenty MiB of original message data. Messages expire after thirty days; download originals you need to retain. Customer-owned receiving domains are outside this release.
Received content is untrusted. The interface displays text without loading remote images or email HTML, sender identity is not verified, and attachments are quarantined rather than virus-scanned. An inbox.received webhook can notify your application using message and inbox IDs; fetch the content only with an authorized credential. Handle duplicate notifications and keep polling as a recovery path.
Open the documentation for the exact endpoints, scopes, limits and retry behavior before connecting a production workflow.