Email SendCan make changes
Send SMTP Email
Send email through SMTP from an explicit agent-supplied message payload.
SMTP provider for send-only email. Acceptance by the SMTP server is not delivery or read confirmation.
Connection facts
What the SMTP connector actually exposes.
These details come from the current StackOS provider manifest and action catalog. They describe the available connection—not a promise that every workflow will use every action.
- Connection method
- smtp-password
- Setup
- SMTP is a protocol, not one vendor. Use the mailbox provider's SMTP settings or app-password page, then enter host, port, TLS mode, username, and password in StackOS.
- Capability groups
- Email Send
- Action boundaries
- 1 write action
Action catalog
Actions listed for SMTP.
Actions listed for this integration. Individual descriptions note availability limits. A workflow still decides which actions belong in the job and where approval is required.
1 matching action
Direct answer
How does the SMTP integration work?
People continue using SMTP as their tool. StackOS adds it to a visible workflow, keeps the work in order, and passes only the approved action to the integration when that stage is ready.
- 01Your requestStart in your AI
- 02StackOS planExpands the steps
- 03SMTPDoes its bounded part
- 04Checked resultKeeps the proof
More from Communications
Related integrations.
Communications
IMAP
IMAP provider for mailbox listing, search, fetch, and message flag lifecycle.
Email Inbox
Communications
Local Agent Chat
StackOS local conversation surface for direct human-to-agent messages, rich response blocks, and interaction events.
Communications
Slack Bot
Slack Web API provider for bot identity, message sends, conversation discovery, membership sync, and signed HTTP ingress.
Messaging
Common questions
SMTP and StackOS.
What can the SMTP integration do in StackOS?
The current catalog includes 1 SMTP action across Email Send. The exact actions used depend on the workflow and approval rules.
Does StackOS replace SMTP?
No. SMTP remains the tool that performs its part of the job. StackOS organizes the workflow, keeps status and dependencies visible, and calls the tool only when the plan reaches the right approved action.