Integration
The tools you already run stay where they are. We connect to them.
Nobody wants to migrate their stack to get a capability. The usual shape of an engagement is that your systems keep doing their job and the document pipeline runs through us — connected the way your engineering team needs it connected.
Integration work is scoped per engagement, not sold as a packaged connector.
Where a connection usually goes
These are the connection points we get asked about most. Which one applies depends on your stack.
Translation and CAT tools
Keeping a linguist workflow intact while documents are processed outside it, so review stays where your reviewers already work.
TMS and project systems
Job hand-off and status visibility, so a project manager does not have to operate a second system to see where a document is.
Content and CMS platforms
Content that originates in a CMS and needs to come back translated without breaking the structure it lives in.
Your own product
Platform vendors embedding the capability behind their own interface — a different conversation with its own scoping.
Your own internal systems
Bespoke internal tooling with its own interface. We map against what you have rather than requiring a standard shape.
How an integration gets built
Four steps. The first two are conversations, not code.
- 01
Describe the system
What it does today, what it can call, and what it cannot change. This is the step that decides everything after it.
- 02
Agree the interface
What goes in, what comes back, what happens when something fails. Written down before anything is built.
- 03
Build and connect
The connection is built against the agreed interface. This is engineering work on both sides.
- 04
Verify against real documents
Not against a synthetic test set. Real files through the real path, checked by the people who will use it.
Why we do not publish a connector list
A list of logos would tell you which tools someone happened to integrate, not whether your situation is workable.
Two agencies running the same TMS can need completely different connections, because what matters is the workflow around the tool rather than the tool itself.
So we do not publish a compatibility matrix, and we do not sell a connector package. We look at your setup and tell you plainly whether the connection is straightforward, involved, or not worth doing.
That answer sometimes is 'not worth doing'. We would rather say so at the start than discover it halfway through a project.
Integration questions
Do you have a plugin for our CAT tool?
We do not publish a list of packaged plugins. Integration is scoped per engagement, because the same tool can need very different connections depending on the workflow around it.
How long does an integration take?
It depends entirely on what is on the other end and what your system can call. We will give you a realistic answer after the first conversation rather than a number now.
Can you connect to something custom we built ourselves?
Often, yes. Bespoke internal systems are a normal case — tell us what it can call and we will tell you what is workable.
Do we need to change our systems?
Usually not. Where a change is unavoidable we will say so up front, because finding out halfway through a project is expensive for both of us.
Is there an integration fee?
We do not discuss pricing on this site at all, for us or for anyone else. Commercial terms are part of the scoping conversation.
What if the integration turns out not to be worth it?
Then we will say so. A connection that costs more than it returns is not a good engagement for either side.
Tell us what is on the other end.
One conversation is usually enough to know whether the connection is straightforward, involved, or not worth doing.
- Describe your stack
- We map the connection
- You get a straight answer