Integrations
Most of the work is the system nobody else will connect.
Anyone can offer a directory of one-click connectors. The integration that actually holds a business back is usually the old one: no public API, a nightly file drop, a database somebody inherited. That is the work we do.
Four levels, described honestly
When a vendor says "integrates with hundreds of systems", they mean the first row. It is worth knowing which row your problem is actually in, because the price and the timeline differ by an order of magnitude.
| Depth | What it means | Who offers it |
|---|---|---|
| Connector | A pre-built link to a popular product. Click, authorise, done. | Everyone. This is the commodity. |
| Documented API | A generic call against a published, well-behaved API. | Most platforms and agencies. |
| No public API | A system that was never designed to be connected to: file exports, SOAP, a direct database, an internal tool with no interface but a login. | Integration specialists, at integration-specialist prices. |
| Connected and governed | The connection above, plus scoped credentials, allowlisted tables, row and column rules, approval before any write, and an audit record of what was read and done. | Very few. This is where we sit. |
What connects today
Gmail and Outlook / Microsoft 365. Read message headers, bodies and attachments in the connected mailbox; draft and send from it after approval.
Files
Google Drive and OneDrive. Documents, spreadsheets, PDFs and plain text, in the folders you select—not the whole drive.
Calendars
Google Calendar and Outlook Calendar. Read events by date range; create and update them once approved.
Databases
PostgreSQL and MySQL. Read and write credentials are separate, and the writable table list must be a subset of the readable one.
Messaging
WhatsApp Business and WeChat Work. Conversation history for the connected account, and sending after approval.
MCP servers
Connect an external MCP server as a source, or expose your own workflows to other AI clients through ours. Both directions, both audit-logged.
Read on demand, not copied. What that means for your data is set out on the security page.
When the system has no API
This is the case that stops most automation projects, and it is more common than vendors admit. The job-management system that has run the business for eleven years. The supplier portal that only produces a CSV. The industry package whose vendor charges for an integration module and then does not build it.
None of that is unsolvable. It is just work, and it needs someone to own it.
Depending on what the system will allow, a connector might be built on:
- a direct, read-only database connection scoped to named tables and columns;
- a scheduled file exchange—CSV, XML or fixed-width—parsed and validated on arrival;
- a SOAP or legacy XML service wrapped in something modern;
- an authenticated session against an internal web application where no other route exists;
- a small connector process running inside your own network, so nothing has to be exposed to the internet.
- What you receive
- A working connector, the rules it enforces, a record of what it reads and writes, and a plain description of what happens when the far end changes or breaks.
- Best fit when
- The information you need is trapped in a system that will not talk to anything, and somebody is currently retyping it.
What a bespoke connector actually involves
We would rather set the expectation properly than quote a number that assumes everything goes well.
The first question is not technical. It is whether anyone still understands the system—what the fields mean, which records are live, which rules are enforced by the software and which by habit. That knowledge is usually in one person’s head, and finding it is often the longest part of the job.
After that: agree exactly what may be read and what may be written, build against real records rather than a sample, run the connector beside the existing process until the output matches, then put it into use with a person approving anything consequential.
Where the far end is fragile or undocumented, we will say so before you commit, and we will tell you when the honest answer is that a connector is not worth building.
- Best fit when
- You want the connection to still work in two years, and you want to know what it does when it fails.
Model Context Protocol
MCP, in both directions
MCP is the standard that lets AI systems reach business tools without a bespoke bridge for every pairing. It moved from a single vendor’s project to shared infrastructure quickly, and it is now governed by the Linux Foundation with the major model providers behind it.
Workmise sits on both sides of it. You can connect an external MCP server as a source, so the agent can use tools we did not build. And an administrator can expose selected Workmise workflows and resources to other AI clients through our endpoint—within the same roles and access grants as everything else, with every invocation recorded.
The practical value is that a connector built once is reachable from more than one place, and you are not committing to a single vendor’s idea of what should connect to what.
Connecting an external MCP server means sending query data to whoever operates it. We do not vet third-party servers, and we will tell you which ones we would not connect.
Tell us which system is the problem.
Bring the one that everything gets retyped into or out of. We will tell you which of the four levels it sits in, what connecting it would involve, and whether it is worth doing.