Integration

Two ways to call the engine. Both stay in your boundary.

Link OfficeAPI as a dynamic library or run it as a process. Either way it runs offline on the platforms your product already ships to.

2 invocation paths5+ languages6 operating systems

The two paths

Dynamic library or process invocation: which should you use?

Both paths call the same engine and produce the same results. The difference is where the engine lives relative to your code.

In-process, lowest overhead

Link OfficeAPI directly into your application. Bindings are provided for Rust, Go, Java, C++, Python, and other popular languages.

RustGoJavaC++Pythonand more

Dynamic library compared with process invocation
Aspect	Dynamic library	Process invocation
Where the engine runs	Inside your application process	In its own process
Language coverage	Rust, Go, Java, C++, Python, and other popular languages	Any language that can start a process
Isolation	Shares your process	Isolated from your application
Overhead	Lowest: in-process calls	One process boundary per call
Offline	Yes	Yes
Operating systems	Windows, Linux, macOS, Android, iOS, HarmonyOS	Windows, Linux, macOS, Android, iOS, HarmonyOS

The contract

Your productOwns the file

Keeps the workflow, storage, and permissions where they already are.

OfficeAPIReads, converts, renders

One Rust core behind both surfaces, running offline.

Your surfaceShows the result

Returns a converted file or a preview to the screen your users are on.

Environment fit

OfficeAPI runs on mainstream desktop, mobile, and server operating systems, so a single integration covers every target.