Connectors

“Just connect the systems” is the phrase that launches a thousand painful integration projects. We sit down to get honest about why connectors in localization and content operations are rarely plug and play, even when a vendor says they have one. Once you’re dealing with hundreds of possible content systems, dozens of TMS options, and different ideas of what a “job,” “string,” or “approval” even means, the real challenge becomes workflow alignment, data modeling, and long-term reliability, not a single technical hookup. 

We dig into the hidden costs: shifting APIs (REST, SOAP, GraphQL), underdeveloped endpoints, and platform changes that can cause automations to fail quietly. At high volume, a small upstream tweak can snowball into a backlog that takes days to unwind, while teams miss delivery windows, ship outdated content, or expose the business to compliance risk. We also talk monitoring beyond “is there a file,” including detecting missing signals, validating formats, and catching mismatched inputs before they become catastrophic. 

Then we map practical alternatives. Direct API integrations can offer more control and less vendor lock-in if you have engineering capacity. Middleware and iPaaS orchestration tools can act as a hub with better visibility across systems. And the most underrated lever is standardization: common exchange formats like XLIFF and JSON, consistent definitions for review and quality, and clearer expectations across stakeholders. If you’re planning an integration, start with discovery, define scope and ROI, match the solution tier to the need, and budget for maintenance from day one. 

Subscribe for more practical conversations on localization technology, workflow automation, and scalable multilingual content, and if this helped, share it with a teammate and leave a review. What’s your biggest connector headache right now?

Transcript

Stephanie Harris-Yee 0:07

Hello.

Why Connectors Are Not Simple

Stephanie Harris-Yee 0:08

So today I am back here with Erik to talk about a new topic. And this one is gonna be connectors. So some of you might be thinking, connectors, what's the big deal? And some of you thinking, connectors, that's right. So Erik, let's start out. And people often say, just connect the systems. Why isn't it that simple?

Erik Vogt 0:30

Yeah, thanks, Steph. This is something that comes up a lot because in our industry, we're heavily focused on the translation part of the system of business that we're operating. And it's really not that simple. Of course, that's a critical part of it. And that's one of the reasons why we're in this industry is to provide translations. But when you think about the systems and how they need to connect to each other, the permutations start getting astronomically complex very, very quickly. So there's hundreds of content systems. There's something like 40 TMSs out there, even if you're only counting the major ones, there's a whole bunch of adjacent tools as well. So I was doing some back of the napkin math, kind of looking at the number of permutations out there of all the different systems that need to talk to each other in our industry. And it very rapidly hits tens and hundreds of thousands. And then there's this natural inclination of buyers to say, oh, you have a connector for such and such. And it's not that simple. The implementation varies. There's lots of customization on each of the different aspects. There's also these systems don't necessarily speak the same language. So as looking at InRiver, for example, they have an entity-driven kind of object level. And then XTM thinks about it in terms of jobs, localized, maybe thinks of it in terms of strings. Each of the approvals at each of these steps could mean different things. So publish, complete, approve. These things all have different meanings. And there's different depths of integration that's possible. So generally speaking, there's very few examples of connectors really being a plug and play kind of mindset. Very often they are very complex, and there's a lot of gray area around what is and is not included in a what a system connection really looks like.

Stephanie Harris-Yee 2:18

Right. So you mentioned a few of the challenges, but it seems like there's a lot of challenges around connectors. And what are some of those that really make it so challenging to build them in the first place? And then also the maintenance aspect.

Erik Vogt 2:32

Yeah. Well,

APIs Change And Maintenance Adds Up

Erik Vogt 2:33

first of all, the API is different. They differ. There's REST, SOAP, Graphic, QL. There's some that are underdeveloped. And they're also continue to be developed. So as these systems evolve, they add features that don't necessarily stay stable. And if you build an automation, let's say it's handling tens or hundreds or even hundreds of thousands of transactions per any given time unit, one piece of those can silently go wrong or stop working correctly. Then you might realize you have a backlog that just builds up without the absence of something isn't always a signal, or you're not even measuring the absence of a signal. And so the building of these systems can be very, very complex and difficult to maintain. The workflow alignment is very difficult. The maintenance is often underestimated. There's sort of this one and done kind of mindset. And very often that doesn't work out. So realistically, it's probably worth considering if you're talking connector. You're also talking about 15 to 30% of the build cost per year just to keep it maintained.

Stephanie Harris-Yee 3:38

Right. And

Backlogs Compliance Risk And Lost ROI

Stephanie Harris-Yee 3:39

then what would be the consequences, I guess, from a business perspective, if it does slip out of maintenance or it doesn't work as expected?

Erik Vogt 3:47

Well, you can have situations as I as I alluded to earlier, where any one of the steps could break, the different integrations could break. Let's say there's a small change upstream, or there's a new use case that hadn't been planned for, and then you end up with a gap and you can miss delivery windows at that point. Not only that, but you can end up with a staggering backlog. There's one project that I was involved with years ago that had such a high velocity that it stopped, I think, for a matter of 12 hours or so. And already at that point, the backlog took several days to catch up with just because the volume was. So you can end up missing product windows, you can end up with the wrong locales, you could end up with outdated content going to the wrong markets. The compliance risks come from that. Generally, the burden falls to PMs often to spend hours chasing files or fixing or reworking, and your ROI just evaporates in that case. So connectors are fragile and there's revenue, there's compliance, and there's some efficiency consequences to not getting the connectors working correctly. So then think about all these extra layers you have to put into it to monitor not only it's not just a watch folder. It's like, is there a file there or not? But now you have to know is there not a file when you were expecting one? Or is the file in the wrong format? Or there's some input criteria which isn't fitting the expected output. And therefore we're running into a situation where backlog can be largely catastrophic very quickly.

Stephanie Harris-Yee 5:21

Wow. Okay. So

API Integrations Middleware And Standards

Stephanie Harris-Yee 5:23

it sounds like connectors might not be the best solution. Are there alternatives that enterprises aren't looking at that you've seen?

Erik Vogt 5:30

Yes. I think sometimes they're looking at direct API integrations. So many software providers, let's say TMSs, will have any published API and a customer or a client can essentially hook from their system straight into these systems without a connector layer. That means working with those API systems directly. You have more control, you have more tailored workflows, and there's really less vendor lock-in at that point as well, which is beneficial. You do need the engineering resources in-house to be able to configure those things. So that's something to consider. There's also middleware systems out there. And I think some of the signals that we're getting from Taos and others is that there's this discussion about orchestration that are talking about IPass, which is an integration uh platform as a service. This is there's high-level, there's things like MuleSoft and Boomi and Mercado. These are kind of high-level business systems that kind of handle a broad range of different systems. Internal to our industry, we've got folks like Blackbird I.O. And then there's domain-specific systems like Lingoport that are focused directly for developer as a developer extension. But there's there's a number of these kind of middleware providers out there that are uh angling to kind of be a hub that helps bridge different entities together. And then there's content standardization, and I think cleaner input pipes lead to better output. Uh, common exchange formats like XLIF and JSON are standard in an industry. You'd be surprised at how many clients are still working with 1980s or 1990s, two early 2000s technology. And they have these excessively complex kind of file management, like just the simple process of separating what you want to translate from what you're not going to translate, or being able to isolate workflows per different content types or different groups, you end up with exceptions per language, exceptions per locale, exceptions per the product line. Companies buy these other different companies over time, and each one has legacy systems. Each of these systems can get very complex. So I think for anybody who's confronting the complexity of their system and looking for a connector, one good way to start is how are you inputting things into the pipeline, into the workflows that are downstream from that, both TMSs, CMSs, LSBs, all these different players thrive and optimize around standardization. So that really makes a big difference in this approach. So there's an opportunity for API first approaches, really focusing on building strategy and getting kind of the right integration approach from the ground up.

Discovery Scoping Costs And ROI

Stephanie Harris-Yee 8:06

Right. So do you have any other tips for someone who's just they know they need some sort of integration besides kind of going through those basic steps you've already you've already mentioned? Is there any ideas on how to approach this in a smart way?

Erik Vogt 8:21

I will always say this start with discovery. Start with an honest conversation about what the, what, what are you really dealing with? What are the options? And very often this is a much more complicated thing than it looks like up front because a key stakeholder, maybe on a localization team, may need to be working upstream with different internal teams that they're dependent on, some of whom may or may not be uh motivated to be particularly helpful. It's uh reality of business. Like sometimes you have to kind of work on this, but a structured approach really helps. And so I'm working on a questionnaire to really define scope and ROI potential in any conversation with any customer with regards to our integrations. But I think in general, this is a good approach. Build a questionnaire, build a system for setting expectations for what's possible. The second is like match the tier need. The basic MVP might be $15,000, $20,000 of investment to try to build a connector, custom connector. It goes up from there, mid-range might be up to $80,000, $100,000, maybe for enterprise implementations. And it can be much more than that, actually. It depends on the complexity and the velocity of the systems. But think about what you're building for and start with the right approach for the right situation. Plan for maintenance. Maintenance is necessary. And then, as always, aligning stakeholders and really defining what you're talking about when you mean connector, it's not just system A versus system B. And the ROI of each of these needs to be against something. So you think about what is it currently costing to get something done? And you might think, well, it's costing a PM 20 minutes a day or four hours a day, or it now I need a team of six project coordinators to be shuttling files around. That starts the conversation for what that ROI looks like. And now you can think about your long-term objectives from there.

Stephanie Harris-Yee 10:17

So,

Where AI Helps And Where It Fails

Stephanie Harris-Yee 10:18

what about AI? Does AI factor in here at all? Does it help? Does it hurt? How does it come into this whole situation?

Erik Vogt 10:25

It's a really good question. It's as tempting as it is to think about AI in this context of file management and task assignments. It's really important to consider that AI, and especially Gen AI, which is the thing that we're focused on the most these days, is not highly deterministic. It can get you close to your target, but often you need a person to make a decision. So you might use AI to monitor an existing connector to look for anomalies, for example. But it's when you need a workflow to work 100% of the time, we're at 99.9% efficiency, then you need something a little bit more deterministic and a little more structured to get that level of confidence. And we don't really want creativity here. You want reliability. So as a result, AI is a little less of an emphasis when it comes to connectors or systems integration. It doesn't mean it doesn't have a role to play within specific systems. So, for example, thinking about booking an AI that helps you with picking up flights for travel. AI can be good at identifying, taking your input natural language criteria to specify a particular parameters for a flight, but you still need somebody to make the decision about whether or not that flight is the right flight or not. And very often the number of permutations there are actually quite large. Number of possible flights, willingness to go through certain hubs, you know, it just adds up. So I think in general, AI can play a role in that selection process as a filtering criteria, but it's not necessarily the right way to think about orchestrator models, except for in very narrow circumstances, which those who are familiar with a space could explain. I would be happy to explain this in more detail in a particular instance. There's just too many permutations to get into right here. But in general, it's a good idea to be thinking about it. But when it comes to connectors, it's a little bit boring, but it's really important to get it right.

Stephanie Harris-Yee 12:28

Okay.

Standardize First Then Build

Stephanie Harris-Yee 12:29

Any last words or thoughts on this topic?

Erik Vogt 12:32

Sure. One, connectors are super powerful. I mean, they're enablers, but they're not magic. So enterprises, you really need to weigh your options. And that means looking at API options, you look at middleware solutions, look at standardization with an emphasis on that last one. Because believe me, number one, so many problems could be solved with strong standardization up front. And I mean standardization not just in terms of file standardization, but just standardization in terms of what the expectations are. How are you defining your terms? What are the process steps that you're trying to deliver here? What does quality look like? What does a review mean? What are the choices that a human in the loop can make in a particular station in a workflow? How does that work? The goal here isn't just to move text between systems, it's to really look at a sustainable, scalable, multilingual content operation thing. So before you build, ask the right questions, start with a discovery framework, and then have a deeper, more focused conversation about how to make the specific business processes more efficient one step at a time.

Stephanie Harris-Yee 13:41

Okay, perfect. Well, thank you so much, Erik.

Erik Vogt 13:44

Thanks, Steph. Look forward to next time.