One API for your agent’s email conversations.

A send endpoint is one part of an agent workflow. Once the recipient replies, your application needs to know which agent owns the address, which conversation the reply belongs to and what has already happened.

Robotomail's API is organized around mailboxes, messages and threads. Provision an address, send from it and receive replies into that same mailbox. Use API keys with the access the integration needs, rather than putting credentials into model-generated text.

The public API base is https://api.robotomail.com/v1. Authenticate with an Authorization: Bearer header. Keep the key on your server. The authentication reference explains key scopes and handling.

Verify your account, then list your mailboxes to obtain a mailbox ID. Send a message with bodyText; optionally include an HTML version with bodyHtml.

curl https://api.robotomail.com/v1/mailboxes \
  -H "Authorization: Bearer $ROBOTOMAIL_API_KEY"

curl -X POST https://api.robotomail.com/v1/mailboxes/MAILBOX_ID/messages \
  -H "Authorization: Bearer $ROBOTOMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":["recipient@example.com"],"subject":"Your request","bodyText":"I have received your request. Reply here with any extra details."}'

Replace MAILBOX_ID with the ID returned by your account. Use a recipient you control for the first test. Store the returned message ID and inspect delivery events; acceptance of the send request is not proof of inbox placement.

For full request and response fields, use the messages reference. Prefer a tested example in the first-send guide before connecting model-generated content.

Register a webhook for message.received, listen to server-sent events or poll the mailbox's messages. A webhook can wake your application; the message and thread APIs provide the context it needs to respond.

When replying, use the original email's RFC Message-ID in inReplyTo. This is different from Robotomail's database ID for the message. Send from the appropriate mailbox, preserve the subject where useful and explicitly check the recipients.

Treat webhook deliveries as notifications that may be retried. Verify the HMAC signature over the raw body before parsing and record processed events or message IDs so your workflow does not repeat a side effect. See receive and reply for a complete implementation path.

Outgoing attachments use an upload flow: upload the file to the attachments endpoint, then include the returned attachment IDs in the send request. Message results expose attachment metadata; retrieve an attachment to obtain a fresh download URL when needed.

For conversation context, fetch the relevant thread rather than feeding an agent the whole mailbox. Page through message lists and keep only the history needed for the task. Filter sent-message retrieval with direction=OUTBOUND when you need to audit what the agent has already sent.

Check attachments, threads and limits when sizing a workflow. Storage is measured at account level; it is separate from monthly sends and inbound usage. See plans and allowances when choosing capacity for a production workflow.

A receipt, activation message or account notice can start a useful conversation. Send it from a mailbox your application monitors so a customer can reply when something goes wrong.

Your application creates the business event, renders the message and controls recipients. For activation emails, it also creates and validates the token, sets expiry and rate-limits resend requests. Robotomail sends the resulting email; it does not issue your application's activation tokens.

Keep sensitive tokens out of analytics and general logs. Do not reveal whether an account exists through the wording or timing of a resend endpoint. The SaaS onboarding example explains how to connect outbound onboarding with inbound help.

Use an application event to trigger an email through the messages API. Store the event-to-message relationship so you can reconcile retries, delivery outcomes and responses.

Your application owns notification preferences, scheduling, digesting, cancellation and any cross-channel orchestration. Check those preferences before sending. Add rate limits for noisy events and give users a clear way to stop optional notifications.

Robotomail supplies email transport and the mailbox where a reply arrives. The inbound email API turns that reply into an event your application can process.

Operating a mail server involves inbound routing, outbound delivery, DNS, queues, storage, abuse handling and ongoing maintenance. A managed mailbox API lets your team spend its effort on the workflow that makes the email useful.

Robotomail provides managed mailboxes and an HTTP API. You still own application availability, safe agent behavior, webhook processing and the DNS changes for a custom domain. Plan limits, recipient behavior and mail-provider filtering still apply.

Before rollout, verify sender identity, run a send-and-reply test, monitor bounces and make a recovery plan for failed requests. See delivery operations.

An SMTP integration asks for a host, port, transport security and an SMTP username and password. Robotomail's documented sending interface uses HTTPS and a bearer API key. Do not place that key into an SMTP password field or assume there is an interchangeable SMTP host.

To migrate, identify where your application currently sends mail, replace that call with the messages endpoint and map sender identities to Robotomail mailboxes. Keep plain text, HTML and attachment handling explicit. Test failure responses and delivery events before moving production traffic.

If your existing software only accepts SMTP settings, it needs an HTTP-capable adapter or an integration change. Review the API reference and language SDKs before choosing the implementation.