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.

01Where the conversation happens

Reach it the way you'd reach a colleague.

Every one of these is two-way, not a notification feed. A droid picks up a thread on email, carries the same work on over a phone call, and remembers both.

  • SlackDMs, and when @mentioned in a channel
  • EmailYour Gmail or Outlook, or a mailbox we provision
  • SMSA real number of its own, so people text it back
  • CalendarReads the day, books the slot, moves the invite
  • In-app chatAlongside everything it's working on
  • WhatsAppWhatsApp Business, voice notes and reactions included
  • Phone callsPlaces them and answers them, live
  • Microsoft TeamsChats and channels, or installed org-wide
  • DiscordDMs, and when @mentioned in a server
  • Meet and Teams callsJoins in a browser, listens, speaks up
  • Your own appA REST endpoint, for anything you built yourself
02Where the record lives

Your accounts, under your own permissions.

One consent screen, scoped to the surfaces you pick. A droid reads and writes as you, so it inherits your access rather than needing an admin to widen anything.

Google Workspace

Gmail · Calendar · Drive · Contacts · Tasks · Meet · Chat

Microsoft 365

Outlook mail · Calendar · OneDrive · Contacts · Teams · SharePoint · To Do

  • HubSpotDeals, contacts, notes
  • AirtableThe board a team actually runs on
  • QuickBooksBills, invoices, reconciliation
  • StripePayments, refunds, subscriptions
  • ZendeskTickets, macros, the queue
03Where the code goes
  • GitHubBranches, PRs, reviews
  • LinearIssues, cycles, triage
  • SentryAlerts, with the trace already read
04The whole catalog

And 1,045 more, already connectable.

A droid searches this catalog mid-task and asks you to authorise what it needs, so nothing here has to be wired up in advance.

Filter

1,045 apps.

  • 1password6 actions
  • 21risk8 actions
  • 2chat5 actions
  • Ably25 actions
  • Abstract3 actions
  • AbuseIPDB6 actions
  • Abyssale4 actions
  • Accredible certificates36 actions
  • Acculynx8 actions
  • ActiveCampaign298 actions
  • ActiveTrail159 actions
  • Addressfinder17 actions
  • Addresszen2 actions
  • Adrapid3 actions
  • Adyntel8 actions
  • Aeroleads1 actions
  • Affinda105 actions
  • Affinity20 actions
  • AgencyZoom99 actions
  • Agent Mail5 actions
  • Agentql3 actions
  • Agenty79 actions
  • Agiled18 actions
  • Agility CMS9 actions
  • Ahrefs40 actions
  • AI/ML API30 actions
  • Airtable24 actions
  • Aivoov1 actions
  • Alchemy36 actions
  • Algodocs3 actions
  • Algolia127 actions
  • All Images AI7 actions
  • Alpaca100 actions
  • Alpha Vantage56 actions
  • Altoviz67 actions
  • AltText.ai10 actions
  • Amara30 actions
  • Ambee27 actions
  • Ambient Weather1 actions
  • Amcards10 actions
  • Amplitude54 actions
  • Anchor Browser64 actions
  • Anonyflow5 actions
  • Anthropic Administrator3 actions
  • Apaleo29 actions
  • API Labz4 actions
  • API Ninjas128 actions
  • API-Sports67 actions
  • API.Bible19 actions
  • API2PDF10 actions
  • Apiflash5 actions
  • Apify112 actions
  • Apify MCP8 actions
  • Apilio8 actions
  • APIpie AI13 actions
  • Apiverve11 actions
  • Apollo48 actions
  • Appcircle14 actions
  • AppDrag11 actions
  • Appointo11 actions
05Access

You grant it like you'd grant a person.

Each connection is scoped and revocable. Credentials are held encrypted and swapped in at call time, so a droid can use a connection without ever reading the token behind it, and the detail is on the security page.

Connections belong to the person who authorised them, which is what keeps a droid's permissions the same as yours.

Connected apps
Slackread · writerevoke
Airtableread · writerevoke
HubSpotread onlyrevoke
Striperead onlyrevoke
FIG. 1Scopes, per app, per workspace: the panel your reviewer will ask for.
06Everything 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.

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

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

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

  4. 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, and gets the data. Anything worth keeping is stored as a reusable function.

07Files 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 query, rather than stuffed into a prompt and half-remembered.

  1. Spreadsheets

    CSV and Excel parsed into queryable tables, not pasted into a prompt

  2. Documents

    PDFs and office files read page by page, including scans

  3. Email attachments

    Pulled off inbound mail and ingested without anyone downloading them

  4. Drive and SharePoint

    Read from the folders you've granted, through your own connection

08Questions

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.

Point a droid at your own stack, or read a worked example. Each one lists the apps and channels it runs across.