Mail & Messaging
Connectors for getting a message — or a notification — out of a flow and into a human’s inbox or channel.
| Connector | invoke: | What it does |
|---|---|---|
| Email (Send) | email.send | Send mail over SMTP — recipients, subject, body, attachments. |
| Email (Fetch) | imap.fetch | Read mail over IMAP — useful as an inbound trigger source. |
using: - environment/prod - zenvara/email
output: message-id: !str
steps: - $email: invoke: email.send on: smtp with: Subject: "Daily order summary for ${date}" Body: "${summary.content}"
- return: message-id: "${email.messageId}"The SMTP/IMAP host and credentials live on the connection, referenced as secrets.
Chat & messaging
Section titled “Chat & messaging”| Connector | invoke: | What it does |
|---|---|---|
| Slack | slack.* | Post messages, upload files, interact with channels. |
| Microsoft Teams | teams.* | Post to Teams channels / chats. |
| Signal | signal.* | Send Signal messages. |
| Zoom | zoom.* | Meetings and Zoom API operations. |
Notify — one abstraction over many channels
Section titled “Notify — one abstraction over many channels”| Connector | invoke: | What it does |
|---|---|---|
| Notify | notify.* | A channel-agnostic notification verb that routes to whichever backend the connection points at. |
Use notify.* when you want a flow to “tell someone” without hard-coding the channel — the environment decides whether that means email, Slack, or Teams, the same way it decides which database db resolves to. This keeps alerting logic portable across environments.
Common pattern: alert on failure
Section titled “Common pattern: alert on failure”Pair a messaging connector with control flow to notify only when something goes wrong:
using: - environment/prod - zenvara/slack
output: ok: !bool
steps: - if: "len(errors) > 0" $alert: create: slack.message on: ops-channel with: Channel: "#ops" Text: "Pipeline ${flow-name} hit ${= len(errors)} errors"
- return: ok: true