An engineering team evaluating localization infrastructure usually asks the wrong first question. They ask "does it have an API?" instead of "which of my systems need programmatic access, and what does each one actually need to call?" A CI/CD pipeline shipping nightly builds needs something different from a coding agent triaging untranslated strings in a pull request, which needs something different again from a support engineer asking Claude to check on an order status. Most localization vendors answer all three with the same webhook-and-token API and call it done. That's a lowest common denominator.
Ollang's position is that enterprises don't need one integration path into localization, they need the right one for each calling system. The platform ships four distinct surfaces, REST API, MCP server, SDK, and Skills, and the engineering discipline here is not any single surface, it is keeping them separate and ensuring they all resolve to the same execution engine underneath. Ollang is a localization platform for video, audio, and document content, and it orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, exposed through APIs, an MCP server, an SDK, and agent Skills. This piece is a system diagram for the engineers who have to decide which door to walk through.
The shared core underneath all four doors
Before picking a surface, it helps to understand what sits beneath all of them, because none of the four are independent products bolted onto a marketing site. The Folder → Project → Order hierarchy is the operational model every request eventually resolves to, regardless of whether it arrived via a curl command, an agent's tool call, an SDK scan, or a natural-language Skill invocation. A Folder groups related work, a Project holds source assets and configuration, and an Order is the unit of execution, the thing that actually gets translated, reviewed, and delivered.
That shared model is what makes multi-surface access safe instead of chaotic. Ollang uses project context, custom instructions, and terminology memory to help agents localize JSON/i18n content with the right regional tone, idioms, and cultural nuance, and that memory does not reset depending on entry point. A term pinned via the dashboard is respected when an MCP-connected agent runs the same project a week later. A glossary built through the API persists when a Skill-driven coding agent touches the same repo. Governance, quality gates, and terminology consistency are properties of the Project and Order objects, not properties of whichever client happened to call them.
REST API: the pipeline builder's surface
For teams building end-to-end custom localization pipelines, source system on one end, delivery target on the other, orchestration logic in between, the REST API is the correct layer. It is API-key authenticated, covering programmatic uploads, orders, projects, revisions, QC, human review, and webhooks.
This is the surface you reach for when localization needs to be a first-class step in a system you already own: a CMS publish hook that creates an Order on every content change, a release pipeline that gates deployment on translation QC status, or an internal admin tool that lets a localization ops team requeue a batch of documents without touching the Ollang dashboard. The API gives you the primitives, folders, projects, orders, revisions, and lets your own orchestration code decide the sequencing, retry logic, and business rules.
The tradeoff is honest, you own the glue. Polling for order completion, handling webhook retries, mapping your internal content model to Ollang's asset types, that's your integration code to write and maintain. What you get in exchange is full control over how localization sits inside a pipeline you already trust, which matters when the pipeline has its own compliance, audit, or sequencing requirements that no vendor-provided abstraction should override.
MCP server: where autonomous agents run workflows directly
The REST API assumes a human engineer wrote the calling code ahead of time. The MCP server assumes the opposite, an autonomous agent needs to discover what's possible and decide, at runtime, which workflow to run. This is the surface built for the agent pattern, not the scripted one.
Ollang runs a hosted Model Context Protocol server, authenticated with OAuth 2.0 + PKCE, that drops into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. The practical difference from the REST API is discovery. An MCP client does not need pre-written integration code for every action, it connects, enumerates the tools the server exposes, and an LLM decides which tool to call and with what arguments based on the task in front of it. A support engineer can ask an agent to "check the status of the German dubbing order for the onboarding video" without anyone having built a status-check UI for that specific phrasing. The agent discovers the order-lookup tool and calls it.
This matters operationally because it removes an entire category of custom glue code, the code you would otherwise write specifically to let an LLM-based tool call your API safely. OAuth 2.0 with PKCE handles the authorization handshake so credentials are not passed around as static bearer tokens in agent config files. The MCP server is the right choice when the caller is not a fixed pipeline but a reasoning system that needs to decide, mid-task, whether to translate, check QC, or route to human review.