SendGrid

A SendGrid integration stores outbound email credentials for Mobius so assistants can send plain, HTML, reply, and templated email.

SendGrid and SMTP2GO 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. Templated email exists on SendGrid only.

Use SendGrid when the assistant sends the mail itself. Use Gmail when mail should be sent from a connected Gmail mailbox.

Capability map

Connect SendGrid

The from address is ordinary configuration. The API key is stored as secret credentials and is never returned by read endpoints.

{
  "name": "default",
  "provider": "sendgrid",
  "credentials": {
    "api_key": "$SENDGRID_API_KEY"
  },
  "config": {
    "from": "briefs@acme.example"
  },
  "controller": { "kind": "organization" }
}

The example makes the key team-managed. In the app, an administrator can choose You for a personal sender or Your team for a company sender. Then use Assistant access on the exact connection and choose its Mobius result audience. The grant does not override SendGrid's verified-sender rules.

Actions

sendgrid.reply
sendgrid.send
sendgrid.send_template

The action prefix is sendgrid. and matches the provider ID sendgrid. Use sendgrid.send_template when subject or body should be rendered from data the assistant already has.

Every SendGrid action changes outside state and runs without an automatic Mobius confirmation after the chosen connection and grant are rechecked. The grant's result audience does not validate message recipients. Use a verified sender, provider-side restrictions, or a narrower sending action when recipient policy must be enforced.

sendgrid.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. 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.

message_id and provider_message_id are not interchangeable

Every SendGrid action returns two identifiers. Passing the wrong one to a reply is the usual reason threading quietly stops working.

message_id changed meaning in this release. It used to carry SendGrid's X-Message-Id, and it now carries the RFC 5322 identifier Mobius stamps. The vendor identifier moved to the new provider_message_id field. A workflow that saved the old message_id and replies against it threads against nothing, so resave the value after the next send.

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.

Every action also returns status and timestamp. These are Mobius's own record of the submission, not anything SendGrid reported: status says Mobius finished the send call and timestamp is when it finished. Neither field is evidence that SendGrid accepted or delivered the mail. For that, look the message up in the SendGrid activity feed by provider_message_id.

Events

SendGrid does not register source events. Start the work another way, such as a message to the assistant or a routine, then call email actions from that turn.

Next

• Manage sender access in Connect accounts.
• Grant email actions to an assistant from actions.
• Review action safety in actions.