Skip to content
Me docs

Integrations

An integration is one account at a provider (a calendar, a mailbox, a Teams sign-in, a phone number, an API key), stored as a connection (conn_…) of a provider plugin. See Concepts → Integrations for how they work and who may add them.

Terminal window
me integration list                              # providers you can set up, their fields, and your connections
me integration add <provider> --help             # one provider's settings as flags; which are secret
me integration add <provider> --name "<name>" [--<setting> <value>…]
me integration test conn_…                       # ask the provider again whether it works
me integration remove conn_…

Rules that apply to every provider:

  • Only a person adds or removes integrations. Agents are refused.
  • Secrets are never flags. me integration add asks for each secret at a hidden prompt. For scripts, pipe them as JSON with --secrets-stdin. A secret passed as a flag is refused.
  • Every connection is checked at once. After saving, me integration add asks the provider whether the account works. When it doesn’t, the answer says why, and the hint gives me integration test and me integration remove.
  • Sign-in providers open your browser. You sign in at the provider, and the server keeps the tokens. --no-browser (or ME_NO_BROWSER=1) prints the link instead. The link works for 10 minutes.
  • Providers that push need a public webhook address. The operator sets it up once with a Cloudflare tunnel. me integration add then prints the connection’s webhook URL, which you give to the provider.

Status

Section titled “Status”
Integration Provider id Status Guide
Microsoft 365 calendar com.me.calendar.m365 On main Microsoft 365
Microsoft Teams com.me.teams On main (push with a tunnel, else polling) Microsoft 365
Microsoft 365 mail, incl. shared mailboxes com.me.mail.m365 On main (push with a tunnel, else polling) Microsoft 365
Microsoft 365 assistant mailbox (app-only) com.me.graph.mail On main, limited Microsoft 365
Telnyx SMS and voicemail com.me.telnyx On main Telnyx
Cloudflare mail (the system’s mailbox) com.me.mail.cloudflare On main Cloudflare mail
Claude as the system’s model (API key or your subscription) com.me.model.anthropic On main Claude
Claude Code development sessions com.me.claude Built, not in the local install yet Claude
Google calendar — Coming soon: PR #120 Google
Gmail — Coming soon: PR #134 Google
Devices (your own computers) com.me.devices Enrolment on main; the connector is coming soon: PR #111 Devices
Slack — Planned —

Also coming soon for Microsoft 365:

  • Teams presence: PR #133.
  • Teams @-mentions reaching attention and triggers: PR #139.
  • One Microsoft app registered by the operator, so that people only sign in: PR #140.

Where the messages go

Section titled “Where the messages go”

Mail, SMS, Teams chats and voicemails all land in one model:

  • A conversation (comms.conversation) holds messages (comms.message). There is one conversation per mail thread, SMS correspondent, or Teams chat or channel.
  • The unified inbox is the comms.triage facet on received messages (new → needs_reply → waiting → done).
Terminal window
me comms conversation list
me comms message list
me find "<something someone wrote>"
me comms reply --message msg_… --body "…"        # waits for your approval: it contacts someone outside

Every received message publishes comms.message.received (plus a channel-specific event such as mail.message.received or sms.message.received), which triggers and workflows can react to. Message text is untrusted data. An agent never follows instructions it finds in a message.