Integrations
Every action a teammate can take, and whether we've tested it
A logo on a marketing page is not a capability. This is the actual catalogue: per capability family, the actions, what each one must be pointed at, how a teammate gets in, and which of them have evidence behind them.
How to read this page
Two different things, deliberately kept apart
Mechanism
How a teammate gets in
A native sign-in in the teammate's own browser, an API key you paste, something local to your workspace computer, or a tool server you host. This says nothing about whether your account works today.
Readiness
Whether the action has been proven
Readiness is raised only by a probe that posts evidence against a real connection. Until that happens an action reads as awaiting evidence — the adapter exists and the proof does not. We would rather tell you than let you find out.
Once connected, every action a teammate runs writes a receipt — the account, the record, the outcome and a redacted diff — including the reads and the calls your scopes denied. Actions are granted per teammate; connecting an account grants nothing on its own, and one connection reaches only the families its provider supports.
The catalogue
Every action, with what it needs and what it proves
Showing 11 of 11 families · 83 actions
Mailbox12 actionsAwaiting evidence
A teammate's own address: provision it, read the threads you scoped, and send or reply only through the approval queue. Search and archive stay inside the mailboxes you granted.
Implemented by worker/src/adapters/mailbox.js
Calendar4 actionsAwaiting evidence
Read the calendars you select, resolve a meeting's join link from its event, and watch for changes. Meeting attendance needs no per-platform conferencing integration.
Implemented by worker/src/adapters/meeting.js
Browser19 actionsAwaiting evidence
What a teammate does on your workspace computer: navigate, read, click, type, upload and download, inside its own profile. A sign-in is filled by the broker from the vault and never returned to the model.
Implemented by worker/src/adapters/browser.js
Browser profiles7 actionsAwaiting evidence
The lifecycle of a teammate's browser profile: create, checkpoint, restore, lock while a human takes control, and move a file deliberately between two profiles.
Implemented by worker/src/adapters/browser.js
Files5 actionsAwaiting evidence
Read, write, list and delete inside the folders you scoped, and export an artefact out of the workspace.
Implemented by worker/src/adapters/files.js
Meetings7 actionsAwaiting evidence
Join from a calendar link as a visible participant, announce what it is, assert the recording authority before capturing anything, transcribe and leave. A join that fails is classified, never dressed as a transcript.
Implemented by worker/src/adapters/meeting.js
Teaching and replay7 actionsAwaiting evidence
Record yourself doing a task once, publish the captured manifest as an editable procedure, and replay a step with assertions. Capture pauses before a sign-in and there is no setting that turns that off.
Implemented by worker/src/adapters/recorder.js
Vault4 actionsAwaiting evidence
Save a credential, read it redacted, rotate it and revoke it. A value is never rendered — the read itself is the receipt.
Implemented by worker/src/adapters/vault.js
Native AI plans7 actionsAwaiting evidence
A plan you already pay for, signed in as itself: begin the native login, probe whether the plan is eligible and the session alive, list its models, execute a checkpoint and classify a failure honestly.
Implemented by worker/src/adapters/native-model.js
AI API keys6 actionsAwaiting evidence
Your own API key: verify it, list what it can reach, complete and embed, classify a failure and revoke. Your key, your bill, and a paid switch always asks first.
Implemented by worker/src/adapters/api-model.js
Hosted tool servers5 actionsAwaiting evidence
A tool server you host: discover what it declares, describe a tool, invoke one you granted, accept a changed manifest deliberately, or quarantine it. Discovery alone never grants execution.
Implemented by worker/src/adapters/mcp.js
AI accounts
A different kind of connection, on purpose
The families above are where the work happens. This is where the thinking is billed. Bring the plan you already pay for, stack more than one, and set which teammate uses which. The column below is the documented sign-in mechanism — it is not a claim that your particular account is eligible, connected, or permitted by that provider on a hosted runtime. A blocked account never renders as connected.
| Provider | Mechanism | Evidence |
|---|---|---|
| Cloudflare Workers AI | api-key | Not yet verified against this runtime. Provider documentation |
| Kimi | api-key | Not yet verified against this runtime. Provider documentation |
| Llama | api-key | Not yet verified against this runtime. Provider documentation |
| MiniMax | api-key | Not yet verified against this runtime. Provider documentation |
| OpenRouter | api-key | Not yet verified against this runtime. Provider documentation |
| Qwen Cloud | api-key | Not yet verified against this runtime. Provider documentation |
| Z.AI/GLM | api-key | Not yet verified against this runtime. Provider documentation |
| ChatGPT | native-plan | Not yet verified against this runtime. Provider documentation |
| Claude & Claude Code | native-plan | Not yet verified against this runtime. Provider documentation |
| Gemini | native-plan | Not yet verified against this runtime. Provider documentation |
| Copilot | unverified | Not yet verified against this runtime. Provider documentation |
| SuperGrok | unverified | Not yet verified against this runtime. Provider documentation |
Each connected account separately reports whether it is ready, at its limit, needs re-authenticating or is unsupported. When one is capped, the job continues from its checkpoint on the next account you authorised — and the account actually in use is always on screen.
Not on the list
Host the tools yourself
A tool server you run is a third thing — not a native integration and not an AI account. Point Crewvia at it, read the schema and permissions each tool declares, then grant the ones you want to a specific teammate. If the server's tools change, the new permissions are quarantined until you accept them again.
What the server contract guarantees
- Discovery lists what the server declares. It never grants execution, and a tool nobody granted is never callable.
- A grant is per teammate and per tool, and the credential the server uses comes from your vault rather than from the model.
- A manifest that changes is quarantined with the difference shown, and stays switched off until an owner accepts it.
A tool server you host is yours: you are responsible for what it does and for the credential it is given.
Connecting one
Four steps, inside your workspace
- 01
Connect the account
A native sign-in in the teammate's own browser profile, or a key you paste into the vault.
- 02
Choose the resources
The folders, channels, mailboxes or calendars it may touch — never “everything” by default.
- 03
Grant it to a teammate
Read-only or read-write, per teammate. No grant means no access, and revoking takes effect at once.
- 04
Watch the first run
Every call it makes shows up as a receipt, including the ones your scopes turned down.
Signing in takes you straight to your workspace's connections screen.