For most of the translation industry's history, translation meant documents. A vendor received a file, returned a translated file, and the cycle (measured in days or weeks) matched how teams worked.
Software broke that model.
Mobile apps, SaaS platforms, and connected devices generate thousands of strings (button labels, error messages, push notifications) that ship continuously, often weekly or daily. Treating those strings like documents (exporting them to spreadsheets, emailing them to vendors, importing the results) cannot keep up with the pace of software releases, and the resulting bottleneck is where most multilingual release problems originate.
The good news is that software teams now have a different option: translation via API. Instead of teams sending files back and forth between client and provider, content flows through a direct connection on a schedule the client controls, which produces faster releases, fewer missed strings, and a narrower flow of information between the two organizations. The sections below examine how the API model works, why the file-based model breaks down for software, and what changes when the file step disappears.
What translation via API actually means
API stands for application programming interface. The term sounds technical, but the idea is straightforward: an API is a direct connection between two software systems that lets them exchange information automatically, without anyone manually moving files between them.
A useful comparison is the difference between paying a vendor by paper check and paying through an automatic bank transfer. The check moves through multiple hands: someone writes it, someone mails it, someone deposits it, and someone waits for it to clear. The bank transfer moves the money on a schedule because the two systems communicate directly.
Translation via API works the same way. The client's system connects to the translation provider's API and sends source content through that connection whenever new or updated content exists. The provider's pipeline takes the content, runs it through translation and review, and makes the completed translations available through the same connection for the client to pull back. No one exports a file, emails a spreadsheet, or imports anything.
When this workflow is the right fit
The API model is a strong fit for some content and a poor fit for others. The question to ask is what kind of content needs translation.
Document content (contracts, user manuals, marketing PDFs, training materials, annual reports) usually works well with the traditional file-based workflow. Documents tend to be self-contained, change occasionally rather than continuously, and move through review as a whole. The file workflow matches how that content moves through a business.
Software content is different. An app or website splits its text into thousands of small pieces (a button label here, an error message there, a confirmation email somewhere else) that update on whatever schedule the product team releases new features. Each release might change a few hundred strings, often spread across dozens of files. Tracking those changes manually and shipping them through a file-based cycle creates friction that delays releases and lets strings reach production untranslated.
The simplest test: if the content lives inside an application, a database, or a content management system (CMS) and changes regularly, the API workflow is almost always the better fit. If the content consists of documents that are translated once and then stay put, the file workflow is fine.
What goes wrong with file-based translation for software
The traditional file-based loop has a predictable shape. Someone on the client's team exports source strings into a file. The file goes to the language service provider, usually by email. The provider translates the file and sends it back. The client imports the translated file into the appropriate system. The cycle repeats for every update and every language. Every step is a place where things can break down, and most do so for the same underlying reason: people are doing work that a system could do better.
Files can break twice on every cycle
Exports are where strings get missed. Someone has to remember which content is ready for translation, find it across multiple systems, and export it in the right format. Any string that doesn't make it into the export waits for the next cycle, which might be weeks away. For a product that ships weekly, that lag is the difference between a translated release and a release that goes out with placeholder text in three languages.
Imports cause the second kind of breakdown. Someone has to load translated files back into the source system, and the file's structure often shifts in transit between the provider and the client. A small inconsistency in character encoding, or a mismatch in the string labels, can break the import and send the file back to the provider for cleanup.
Versions multiply across email threads
File exchanges are where versions get tangled. A file named "strings-v3-FINAL" sits in one inbox while a newer "strings-v4 " sits in another. Figuring out which version is current eats time and produces errors.
Tracking what changed eats the most time
Between one cycle and the next, the client's team usually has to identify what changed in the source content, mark it for translation, and verify on the way back that every change came through. That comparison work produces nothing of lasting value and exists only because the file workflow needs it.
The deeper problem is that every step requires someone to do something on a set schedule. People go on vacation, miss messages, and forget to attach files. The file workflow assumes someone will catch the gaps, but the gaps are usually what cause missed strings and late releases.
What changes with an API workflow
The API workflow removes most of those failure points by removing the steps that create them. Instead of asking a person to remember an export, pack the right strings, find the latest file, or hand-track which version is current, the connection between the two systems handles all of that automatically. What used to be a stack of manual handoffs becomes a single ongoing connection that runs on its own.
The manual work goes away
Content moves between the client's system and the translation provider through the API connection. The intermediate file step doesn't exist, which means no exports, no imports, no email attachments, no version confusion, and no format problems.
Every time the client's system sends content to the translation provider, the provider's API recognizes which strings are new, which have changed, and which are already translated. The client's team does not have to compare versions, highlight updates, or mark strings for translation. The provider handles the comparison automatically.
Cycles become predictable
Translation happens on a schedule the client sets (weekly, monthly, or aligned with the product release cycle) rather than relying on someone to manually start each cycle. The next scheduled run automatically picks up any new content.
The client's system can also send its entire string set on every cycle without any cost penalty because the provider's API ignores strings it has already translated. That design removes the human judgment call about what to include in an export, and the judgment call is where strings most often slip through.
Releases move faster
With no manual coordination between cycles, the time from new source content to translated content shrinks dramatically. A localization process that took weeks per release in the file workflow can often run on a weekly cadence in the API workflow. Translation reuse compounds the benefit: when the provider has a record of every translation it has approved previously, it can automatically apply those translations to identical or near-identical new strings, reducing the amount of new work each cycle requires.
Control and security improve at the same time
The client decides when each cycle runs, what content goes in, and what stays out. The team sees status in real time rather than chasing it through email threads. At a glance, anyone on the team can tell which languages are done, which are in review, and which haven't started yet.
Security and privacy are the other half of that picture. The client only sends the specific text that needs translation. The provider never has access to the client's content management system, codebase, or database. Nothing else crosses the boundary between the two organizations.
For clients in healthcare, legal, financial services, or life sciences, the difference is meaningful. A narrower flow of information between client and provider is easier to defend in a compliance review than a portal full of historical file uploads, each one containing whatever the client happened to export at the time.
Closing the loop
The file-based translation workflow made sense when most translation was document translation, and a cycle measured in days or weeks matched the pace of business work.
Software broke both conditions.
Applications and platforms ship continuously, the content inside them changes constantly, and the file-handling overhead is no longer something a localization team can absorb alongside other responsibilities.
An API-based workflow returns that time. The manual coordination moves into a system that runs in the background, and the team's job changes from managing file exchanges to managing translation strategy itself: which markets to enter, what content to prioritize, and how to measure quality.
If any of this sounds useful, check out Argo Translation Strings.
The page covers the four kinds of software content the API is built for, walks through how a translation cycle runs in practice, and answers the questions most teams ask before getting started.
