Google Workspace
- Gmail
- Calendar
- Drive
- Contacts
- Tasks
- Meet
- Chat
Integrations
It works in the tools you already have.
A droid is only useful if it can reach the same places you can. So it lives on the channels your team already uses, connects to your accounts under your own permissions, and falls back to a browser for the software that never got an API.
Connect your own accounts
OAuth or API key
Browser when there's no API
Writes its own when there's neither
Channels
Reach it the way you'd reach a colleague.
Every one of these is a two-way channel, not a notification feed. A droid picks up a thread on email, carries on the same piece of work over a phone call, and remembers both — the conversation follows the person, not the app.
| Channel | How it works |
|---|---|
| In-app chat | In the Unify console, alongside everything it's working on |
| From your Gmail or Outlook, or from a mailbox we provision for it | |
| SMS | From a real number of its own, so people can just text it back |
| Over WhatsApp Business, including voice notes and reactions | |
| Phone calls | Places them and answers them, live, on its own number |
| Slack | In direct messages, and when @mentioned in a channel |
| Microsoft Teams | In chats and channels, or as a bot your admin installs org-wide |
| Discord | In direct messages, and when @mentioned in a server |
| Google Meet and Teams calls | Joins in a browser, listens, and speaks up when it should |
| Your own app | Over a REST endpoint, for anything you've built yourself |
Your workspace
Google and Microsoft, connected properly.
One consent screen, scoped to the surfaces you pick. A droid reads and writes as you, which means it inherits your access rather than needing an admin to widen anything.
Microsoft 365
- Outlook mail
- Calendar
- OneDrive
- Contacts
- Teams
- SharePoint
- To Do
Everything else
Four ways in, in order of preference.
Most platforms have exactly one answer to "do you support this tool?" and it's a list. We'd rather a droid exhausted every route before telling you no.
01
It connects to the account, not to a copy of your data
You authorise a droid the way you'd authorise a new hire — through the app's own OAuth screen, or with an API key you paste in once. Credentials are held encrypted and swapped in at call time; the model never sees the secret itself.
02
It finds the tool when it needs it
Nobody sits down and pre-wires a hundred connectors. A droid searches the catalog mid-task, and if what it needs isn't connected yet it asks you to authorise it rather than guessing or failing quietly.
03
If the tool has no API, it uses the browser
Plenty of the software a team depends on has no usable API — an old portal, a supplier's booking system, a council website. A droid gets its own desktop and browser and clicks through it the way a person would. With permission it can drive your machine instead, for the things that only work from inside your network.
04
If there's no integration at all, it writes one
Droids run real code. Given an endpoint and a token, one writes the request, installs whatever library it needs for the task, and gets the data. Anything that turns out to be worth keeping gets stored as a reusable function, so the second time it's a single call.
Files and data
The attachment nobody wants to open.
Work arrives as files far more often than as API calls. Anything a droid receives gets parsed into something it can actually query, rather than stuffed into a prompt and half-remembered.
Spreadsheets
CSV and Excel parsed into queryable tables, not pasted into a prompt
Documents
PDFs and office files read page by page, including scans
Email attachments
Pulled off inbound mail and ingested without anyone downloading them
Drive and SharePoint
Read from the folders you've granted, through your own connection
Questions
The ones we get every week.
Do you integrate with a specific tool?
Most likely, and there are three routes. Common SaaS tools are in the connected-app catalog and take one OAuth click. Anything with a public API can be reached directly by a droid writing the call. Anything with neither still works through the browser. If it's a tool you'd like first-class support for, tell us and we'll look at building it properly.
Who holds the credentials?
We do, encrypted, and they are injected at the moment of the call rather than handed to the model. A droid can use a connection without ever being able to read the token behind it. There's more detail on that architecture on the security page.
Can different people connect different accounts?
Yes. Connections belong to the person who authorised them, so a droid acting for you uses your access and not a shared service account. That's what keeps its permissions the same as yours.
What happens when a connection expires or is revoked?
The droid notices, stops, and tells you which connection needs re-authorising rather than reporting the task as done. Silent failure is the thing we work hardest to avoid.
Can it work with our internal systems?
If it's reachable over HTTP, yes — a droid can call it directly and you can store the pattern as a function for reuse. If it's only reachable from inside your network, the browser route on a linked machine usually covers it. Talk to us about the awkward ones.
See it inside your stack.
The fastest way to find out whether this works for your tools is to point a droid at them. Or read a worked example first — each one lists the apps and channels it runs across.