Your product already holds the documents. Make it edit them too.
If you build a CRM, an ERP, a document management system or a portal, your users already keep .xlsx, .docx and .pptx inside it — and leave it to edit them. SumOffice is the engine that closes that gap: it runs inside your product, on your infrastructure, under your authorization, and you pay for the application rather than for the people using it.
Four ways to put the engine inside your product
The same three cores — spreadsheets, documents, presentations — delivered in the shape your product needs. Storage and authorization stay yours in every one of them: the engine asks your system who the person is and which file to open.
| In your code | A library for Python, Node.js, .NET and Java (2026.4.3, published in PyPI, npm, NuGet and Maven Central). The native cores ship inside the package: nothing compiles on install, and no Office or LibreOffice is needed. |
|---|---|
| In your app’s window | The local editor — your WebView talks to one binary over a local port or stdio. The developer ladder walks through the handshake and the document events. |
| On your phones | Mobile SDKs for Android and iOS — the editor surface inside your own app, rung 3. |
| In your infrastructure | Server images: a cabin per user and document, your storage behind two URLs, your authorization in front. See SumOffice Embedded and the WOPI contract. |
How far along each of these is — feature by feature, with the measurement behind every cell — is one table: what works where. We would rather you read it before you plan a sprint.
Architecture: office as a capability, not as an application
SQLite did not ask you to launch a database server. FFmpeg did not ask you to open a video editor. WebKit did not ask you to start a browser. Each of them turned a heavy application into a capability you call from your own code — and the products built on top stopped looking like someone else’s software with your logo on it.
Office is the last of those to make the move. The surface belongs to your product. The computing capability belongs to the engine. That is the whole architectural idea behind SumOffice, and it is what the two pictures below differ about.
What we claim, and what each claim rests on
| The engine is the library | The native cores ship inside the packages on PyPI, npm, nuget.org and Maven Central and are called from your code — no office application is launched, and none has to be installed. Measured 03.10.2026 on clean Linux, macOS (including macOS 15) and Windows machines. |
|---|---|
| No identity layer, no cloud of ours | No login, no AppKey, no service to register with: 30 documents a day are free, and beyond that you drop in a key file that works offline. |
| A pinned version | The package number is the core number: 2026.4.3 of the library is 2026.4.3 of the engine. Nothing updates underneath you. |
| You pick the process boundary | In-process library, a helper process over stdio, or a container — the same engine in all three. The boundary is an architectural decision, and it stays yours. |
| Mobile SDKs run on the device | The native core sits in your app: no network and no service of ours is required. Acceptance on Android and iOS, 03.10.2026. |
What the libraries do not do, so that nobody plans a sprint around it: they keep macros and Power Query inside the file, they do not run or refresh them. Running a macro on a copy belongs to the editor; MCP reads and plans. For an agent the library scenario is “file → operation → result” for formulas, recalculation, text and slides.
What WPS publishes about its own architecture
Quoted from their documentation, read on 3 October 2026. Where their pages do not say something, we write “we did not find it published” — not “they do not have it”.
| A callback service is required | Integration has three parts: create a WebOffice application, implement a callback service on your server, and embed the front-end SDK — principle overview. The gateway “needs a public domain name or IP so that the WebOffice service can reach it” — integration flow. |
|---|---|
| One process per document, up to 200 people | “A single document process supports at most 200 people editing online at the same time”; “each document corresponds to a process inside the system”, and that process “uses the kernel library to process the document” — principle overview. |
| An application identity | A created application carries an AppID and AppSecret, and the AppID is passed into the document initialisation call; a production application additionally needs a purchased package and a review — integration flow. |
| Their strength, plainly | The document API “follows the VBA style and is in principle compatible with VBA interfaces and parameters” — integration flow. If you are migrating an integration that already drives Application.Run, Workbooks and Range, that breadth is a real advantage, and we do not have an equivalent object model. |
We did not find published pages for several things that are sometimes said about WPS — among them a library that runs without launching the office application, and the rules for a native document component on mobile. We leave them out rather than guess.
One licence per application, not per person
Embedding is licensed per embedding application: not per seat, not per document, not per click, self-hosted and white-label, with updates and engineering support included. The wording is on the Embedded and licensing pages, and it is the same wording we sign.
For you this means the arithmetic of your own pricing does not change when a customer adds a hundred users or opens ten thousand files a month. That is the part most engines get wrong for a product maker.
Control: the engine does nothing to a file behind your back
| Macros run on a copy | A macro you inherited runs against a copy of the workbook, and the changes are shown to the person before they are applied — the original is untouched until someone agrees. |
|---|---|
| External objects are refused first | Links and objects that would reach outside the file are named and refused before anything touches the document, not after. |
| The macro project survives | vbaProject.bin comes back byte for byte after a save — measured in the library smoke tests and in the connector rounds. |
| Nothing leaves the machine | No account, no external cloud, no telemetry of your documents. The file goes from your storage to your engine and back. |
What each way of delivering the engine does today is in the same table.
An agent can read the document the way the engine reads it
Your product probably has an assistant by now. The MCP server hands it the structure of a real file — sheets and used ranges, formulas, the sources of the macros, the steps of a Power Query — instead of a flattened text dump. In this version the agent reads and plans: running macros and refreshing queries are not part of it, and we say so on that page.
What is the same as everyone else — honestly
A product maker deciding between engines deserves to know where we are not different:
- Editing Office files is table stakes. Every serious suite opens and saves .xlsx, .docx and .pptx; we are not claiming a category of our own for that.
- Mobile apps exist on all sides. Ours are published; so are theirs.
- An AI assistant is in every suite this year. The difference is not that we have one — it is what we hand it (see above) and that it runs where your documents already are.
- Price per seat for end users — if you are buying an office suite for staff rather than embedding an engine, the usual suites are a reasonable choice, and we will say so.
Our difference is narrow and deliberate: the engine goes inside your product, on your terms, and does nothing to the file without showing you.
Where to start
Open a live cabin on a real file, then take the shape you need from the ladder. If you want the engine under your own name, the terms are on Embedded; a pilot is the usual first step and its fee counts toward the licence. Questions go to hello@sumoffice.com — a person answers.