Integrations

An SMTP2GO integration stores outbound email credentials for Mobius so assistants can send plain text and HTML mail, and reply on an existing thread.

SMTP2GO and SendGrid are separate integrations. Each one is its own provider with its own actions, so an assistant sends through whichever vendor's action it was granted. There is no shared email action and no vendor picker. Use Gmail instead when mail should go out from a connected Gmail mailbox.

Capability map

Connect SMTP2GO

Both values are required. The API key is stored as secret credentials and is never returned by read endpoints. The From address is ordinary configuration, so the app can show you which sender a connection uses.

SMTP2GO refuses to send from an address it has not verified, and there is no sensible default sender to fall back on. Mobius therefore rejects a connection with an empty From address when it builds the client, rather than letting every send fail at the vendor. Verify the sender first, in SMTP2GO under Sending on the Verified Senders page, then connect using that exact address.

{
  "name": "default",
  "provider": "smtp2go",
  "credentials": {
    "api_key": "$SMTP2GO_API_KEY"
  },
  "config": {
    "from": "briefs@acme.example"
  }
}

Account limits

The hourly throttle is lifted by verifying a sender domain. Verifying a single sender address is enough to start sending, but it does not lift that throttle, so an assistant that mails in bursts still queues behind it.

The daily and monthly allowances belong to the plan and apply on top of each other. An assistant that mails on every run can exhaust 200 in a single busy day without coming close to the monthly figure, so plan against the daily cap first. See Free Plan and Quota Usage Notifications.

Actions

smtp2go.reply
smtp2go.send

The action prefix is smtp2go. and matches the provider ID smtp2go.

smtp2go.send takes recipients in to, cc, and bcc, a subject, a plain text body, an HTML html_body, a reply_to address, and attachments. At least one to recipient and a subject are required, along with at least one of body and html_body. SMTP2GO refuses a send that carries neither, so Mobius rejects it before the call goes out.

smtp2go.reply takes the message_id of the mail being answered, a single to address, a plain text or HTML body, and the subject of the message it is answering. As with the send action, at least one of body and html_body must be present. Mobius adds a Re: prefix to that subject unless it already carries one, and falls back to a bare Re: when no subject is supplied. Mobius also sets In-Reply-To on the reply and extends its References chain, which is what a mail client reads when it decides where a reply belongs.

There is no smtp2go.send_template action in this release. Templated email exists on SendGrid only, as sendgrid.send_template. To get the same result here, render the subject and body in the assistant and pass them to smtp2go.send.

message_id and provider_message_id are not interchangeable

Both actions return two identifiers. Passing the wrong one to a reply is the usual reason threading quietly stops working.

provider_message_id never travels with the mail, so no recipient's mail client has ever seen it. A reply built from it threads against nothing and lands as a brand new conversation. Keep message_id on whatever record the assistant holds about the conversation, such as a table row, and read it back when the assistant replies.

The reply action returns in_reply_to, the identifier it threaded against, along with a fresh message_id of its own for the reply it just sent. To reply again further down the same thread, pass that newer message_id.

Both actions also return status and timestamp. These are Mobius's own record of the submission, not anything SMTP2GO reported: status says Mobius finished the send call and timestamp is when it finished. SMTP2GO returns no delivery status or acceptance time on this API, so neither field is evidence that the mail was accepted or delivered. For that, look the message up in the SMTP2GO activity feed by provider_message_id.

Partial delivery is terminal

SMTP2GO answers a send with HTTP 200 and a per recipient tally, so one call can accept the message for some recipients and refuse it for others. When Mobius sees that outcome it reports the send as a terminal failure rather than something to retry: a retry would deliver the message a second time to everyone in the original to, cc and bcc lists, including the recipients who already received it. The job that ran the action is not queued again, and the error names which recipients the provider reported as failed, which recipients its tally accounts for as delivered, and which recipients it leaves unresolved, so an operator can see what actually went out and send again by hand to the ones that did not receive it.

A recipient is reported as delivered only when SMTP2GO's own numbers add up. If the response says one recipient succeeded and two recipients go unnamed by its failure messages, both of those recipients are reported as unresolved, because the response does not say which one of them received the message. The same holds when the tally counts more successes than there are recipients left unnamed, which a bcc list can produce.

That protection covers a partial delivery SMTP2GO reported back to Mobius. It is not at most once delivery. If SMTP2GO accepts the message and the worker running the action stops before it reports the outcome, nothing ever records that the send happened: the job's lease expires, the reaper returns the job to pending while it still has attempts left, another worker claims it, and the message goes out a second time. The terminal classification cannot help there, because no failure was ever reported. Closing that gap needs an idempotency key on the send, which Mobius does not have today.

When SMTP2GO reports that nothing was delivered, no recipient can receive a duplicate and the send is retried normally.

Headers

SMTP2GO has no dedicated reply to field on its send API, so a reply_to address travels as a custom header on the message instead. Mobius adds tracing headers of its own as well, including X-Mobius-Source, X-Mobius-Run-ID, X-Mobius-Step-Key, and X-Mobius-Outbound-ID, so a delivered message can be traced back to the run and the step that sent it.

Events

SMTP2GO registers no source events, and Mobius does not receive inbound mail through SMTP2GO. Incoming mail reaches Mobius through a Cloudflare email Worker, which posts to the platform's inbound email endpoint and raises the email.received event. That path is independent of which vendor sends your outbound mail. Replies on an inbound conversation are handled by the SendGrid messaging provider rather than by SMTP2GO.

Start the work another way, such as a message to the assistant or a routine, then call the SMTP2GO actions from that turn.

Next

• Keep credentials in integrations.
• Grant email actions to an assistant from actions.
• Review action safety in actions.