Embed into a desktop application

Your product is a program installed on people’s computers: an accounting system, an industry platform, an ERP add-on, a document management system. Today, to fix a contract, the user exports the file, opens it in someone else’s editor and uploads it back — and along the way versions, permissions and the trail of who changed what are lost.

After these steps, the document opens inside your program, and you know about every change: the file never leaves your system, and every edit passes through it.

How it works, in a nutshell

A separate process runs alongside your program — the document processor, that is, another program on the same machine. Your program sends it a job and gets a response, as in an exchange with any external system. You don’t need to embed libraries into your code, and the language your product is written in doesn’t matter.

If you have a team that has built an exchange with an external system, this path is familiar to them.

Three steps

This section is for whoever will do the integration. If you’re deciding rather than integrating, it’s enough to know: one file from the delivery is placed next to your program and started, and from then on a document is opened, edited, and saved with three jobs.

1. Put the core next to your program. It’s a single executable from the delivery — the document processor. No installer, no dependencies. Builds for macOS (Apple Silicon and Intel), Windows (x64 and arm64) and Linux (x86-64) are openly available, with checksums alongside; where the core is inside them is in Installation and verification. From here on we call it $CLI.

2. Start it as a child process. One command, and it waits for tasks. Its first line says that it is ready.

   "$CLI" serve

   The reply is a readiness line; from it your program knows it can start working:

   {"ready": true, "schema": "fastdoc.session-serve.v1"}

3. Send three lines. Open the document, change it, save it. Each gets exactly one line in reply:

   {"id":"1","cmd":"open","path":"/path/contract.docx"}
   {"id":"2","cmd":"mutate","operation_kind":"insert-text","paragraph_index":0,"offset":0,"text":"Hello. "}
   {"id":"3","cmd":"save","path":"/path/contract-new.docx"}

   The replies look like this:

   {"id":"1","ok":true}
   {"id":"2","ok":true}
   {"id":"3","ok":true}

   A new file with the edit appears on disk. This is not a made-up example: exactly this exchange was run on an installed SumDoc while preparing this page.

What to know right away

A refusal comes before the change, not after. If the operation isn’t supported or the document is protected, you get a response with the reason, and the file stays as it was. There’s no such thing as a half-written document: the file is written in one atomic action.

Starting, stopping, and restarting are on your side. The processor lives as long as your program does; when you close the window, close it too.

For developers. The id field is returned in the response — you use it to match the job and the response in your logs. The processor answers strictly in order, in the sequence the jobs arrived, so a long operation delays everything sent after it. If you need parallelism, start a second process.

Show a document without the editor

When a document only needs to be viewed — in a report, in an email, on a machine without your program — no editor is needed at all:

"$CLI" render contract.docx -o contract.html

The result is a single HTML file: it opens with a double-click in any browser, with no server or network, for viewing only. The pages look the same as in the editor, and whatever isn’t drawn is honestly marked.

If you need to show the editor itself

The three jobs above change the document without any screen — that’s enough for reports, templates, and batch processing. When the user needs to see the document and edit it by hand, you have two paths:

A window inside your program

Your application opens the surface address in the system web view — and gets a ready-made editor inside its own window.

Embedding the surface

A separate editor window

The simplest option for a first trial: the editor opens in its own window, and your program hands it the file and collects the result.

Starting the surface

The same for spreadsheets

Excel spreadsheets work the same way: their own processor runs alongside, and the exchange uses the same kind of jobs. What differs is the program name, the set of jobs, and one thing in the exchange itself: a workbook with external data sources can ask your program a question back — the processor has no network of its own, so it turns to you for data. Documents never do that, so the exchange for spreadsheets is written separately — A separate core process next to the application.

If computing has to happen on a server rather than on the user’s computer, the same processor works there too: The processor on a server.

Further on, when the simple path is not enough

What you want to do	Where to look
Build a contract from a template and fill in data from your database	What SumDoc can do with a document
Export the finished document to PDF, including with embedded fonts	Printing and publishing
Check how a third-party file is protected and which macros it has, without running them	File security
Recalculate a workbook, build a pivot table, refresh a data query	Capability map next to Excel
Understand what comes in a reply and how to read a refusal	Request and response objects
The exact names of all calls, with fields	SumDoc reference, SumSheet reference

Embed into a web applicationIf your product lives in the browser: the editor opens right on your page.

Embed into a mobile applicationWhat is possible on a phone and a tablet today and what is not yet — honestly and without promises.