Platform overview: Product picture, white-label delivery, security, pilot. # What embedding gives you that Office doesn't > Eight measurable axes where an embeddable platform gives you more than a ready-made editor, and the areas where superiority can't be claimed without testing. An advantage only matters where it can be measured. Below are eight axes where an embeddable platform gives you more than a ready-made editor, and how each claim is verified on your documents before the contract is signed. | Axis | What it gives you | How to verify it | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Embedding as the foundation | What you get is your product, not an editor inside someone else’s environment. | Take the [evaluation kit](/start/glossary/) and embed a real document in your application within the allotted time. | | One owner of meaning | One core parses, calculates, and writes the file; there is no second formula engine or history in the interface, and the result is the same in the desktop app and in the browser. | Run the same operation in the desktop app and in the browser, and compare the content, formulas, history, and the written file. Pagination is not part of the comparison: text width is measured by the system where the core runs, and the desktop app on macOS may not match the server core on Linux. | | Refusal before mutation | An unsupported operation doesn’t corrupt the file. | Check four cases — a stale revision, sheet or document protection, read-only mode, a corrupted file — and confirm that not a single byte changed. | | Preservation as a commitment | Power Query, macros, unfamiliar markup, charts, and relationships between parts of the file survive a save. | Compare the file’s content before and after, and reopen it in a new process. | | A contract ready for agents | An agent’s work becomes manageable and verifiable. | Walk through the “preview → confirm → apply → roll back” scenario and confirm that every step is recorded. | | One layer for desktop and web | Offline work and the browser are served by one core. The path to the browser differs between the products: spreadsheets calculate right in the browser, documents use the core on the server, one process per user. | Compare the meaning of the same operations in your chosen pair of environments — [SumSheet runtimes](/sumsheet/environments/), [the SumDoc editor in the browser](/sumdoc/webhost/). | | Lifecycle and shutdown | The embedded editor runs for a long time, without leaks or hung processes. | Open and close the editor repeatedly, and confirm that no listeners, background threads, or processes are left behind. | | A capability matrix as part of the contract | Less risk of false promises and of disputes after the rollout. | An agreed matrix: formats × runtime × operations × limits. | ## Where you shouldn’t promise superiority without testing [Section titled “Where you shouldn’t promise superiority without testing”](#where-you-shouldnt-promise-superiority-without-testing) * The total number of interface features compared with mature office suites. * Full compatibility with Word and Excel in every rare edge case. * Speed superiority over other suites without an identical set of documents and an identical measurement method. * Full support for VBA and the M language without a separate compatibility matrix. * Simultaneous editing of objects and formatting by several people: co-editing is proven for text and cells (measured with five participants and 119 scenarios); objects and formatting under concurrent input are still being measured. * A ready-made server service for production load — queues, quotas, monitoring — if it isn’t part of the capability profile. ## Next [Section titled “Next”](#next) * What exactly the product does with the file — the [SumDoc capability map](/sumdoc/capabilities/) and the [map next to Excel](/sumsheet/atlas/). * How verification on your documents works — [Pilot and acceptance](/platform/pilot/). * What’s not there yet, and how that gap is covered — [Risks and honest boundaries](/platform/risks/). # VBA, Power Query, and agents > Automation without losing control: a supported subset instead of blanket promises, a Power Query ladder, and agent work as a transaction. The most common question when moving away from Excel is “will my macros and queries come along?”. The honest answer: some will, some won’t, and the main thing is to find out before the rollout, not after. The platform is built so that what’s unsupported doesn’t break the file silently but is named explicitly, and a change can be seen before it’s applied. ## VBA [Section titled “VBA”](#vba) Full VBA compatibility isn’t promised. The supported subset runs; everything else is rejected with a clear reason — before the document changes. For documents the rule is stricter: running macros isn’t promised at all, and reading their contents is separated from running them. | Where | What’s promised | What isn’t promised | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Spreadsheets (SumSheet) | VBA compatibility as a separate capability on top of the operations contract; unsupported language constructs, application calls, and attempts to cross security boundaries are rejected with a stated reason. | Full compatibility with Excel VBA — without an agreed set of workbooks, security requirements, and a matrix of supported calls. | | Documents (SumDoc) | Detecting macros and their printable strings without running them; business-logic events through the public event set and policy enforcement points. | Parsing macros into source code, running them, and an Office.js-compatible environment — without a separate agreement. | | Enterprise automation | The “inspect → propose → confirm → apply” order, role-based restrictions, protection against repeated execution, an action log. | An agent that clicks through the interface or edits the file directly. | ## Power Query and data workbooks [Section titled “Power Query and data workbooks”](#power-query-and-data-workbooks) Power Query is a strength for enterprise rollouts, but it needs to be discussed in steps, not with the single word “supported”. It’s not a full match with Excel: the declared subset works, the rest is rejected with a stated reason. * **Recognize.** Find the queries, connections, data model, and anything unsupported in the workbook. * **Preserve.** Don’t delete, on write, anything the operation doesn’t manage. * **Show.** Reveal the query structure without exposing credentials or handing over the whole workbook. * **Refresh.** Run agreed sources and transformations — within the bounds of the declared capabilities and set rules. * **Create.** Add and change queries and connections within the confirmed subset. There are contract operations for every step — 61 of them, spread across seven sections of the reference. ## Agents [Section titled “Agents”](#agents) The agent works not by clicking and not by editing the file, but through the same contract as the interface. It has stable object identifiers, a revision check before a change, policy enforcement points, a preview of the result, and the ability to confirm or roll back. ## For developers [Section titled “For developers”](#for-developers) * Macros and VBA in SumSheet — [the reference section](/reference/sumsheet/vba/). Checking SumDoc macros without running them — the `inspect-vba` command: [what else the processor does](/sumdoc/overview/#what-else-the-processor-does-besides-editing). * Power Query, 61 operations, spread across seven sections of the reference: [queries and steps](/reference/sumsheet/pq-queries/) — 13, [connectors](/reference/sumsheet/pq-connectors/) — 13, [M expressions](/reference/sumsheet/pq-expressions/) — 9, [execution and progress](/reference/sumsheet/pq-execution/) — 9, [tables from queries](/reference/sumsheet/pq-tables/) — 8, [trust and privacy](/reference/sumsheet/pq-trust/) — 6, [external mashups](/reference/sumsheet/pq-mashup/) — 3; the list with the numbers is in the [reference overview](/reference/sumsheet/overview/). * The agent’s route for documents today is the same session commands a person uses, all 41 of them: [session commands](/reference/sumdoc/session-protocol/). There’s no separate interface for the agent; it’s [only proposed](/sumdoc/host-api/). A repeated call with the same identifier isn’t executed twice. # Commercial packaging > The commercial model: units of delivery, the licensing model and prices, the key and the modes without one, partnership levels. You buy the right to embed the engine and managed compatibility, not the source code. That means a supported runtime with commitments on compatibility and updates, not a fork you would then have to maintain yourself. | Deal component | What it is | Why it matters | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | The right to embed | The right to embed and distribute SumOffice under your brand. | The legal basis for delivering it under your own name. | | Access to the developer kit | Built packages, types, the public interface, examples, and documentation. For documents, the public contract works today; for spreadsheets, the set is still being separated from the internal contract, and its current contents are a matter of the agreement, not a default. | Integration goes through a stable contract, not internal details. | | Capability profile | A named set of features, platforms, formats, embedding methods, and limits. | This, not general phrases, is what defines the commercial promise. | | Integration package | Joint development of an adapter for your application, storage handling, and an acceptance scenario. | Reduces the risk of a failed pilot. | | Automation modules | An interface for agents, VBA compatibility, Power Query, and data connections — each with its own profile. | The base editor delivery isn’t mixed with what needs separate verification. | | Version support and commitments | The support period, security fixes, the update cadence, the compatibility period. | Enterprise rollout depends on how predictable these timelines are. | | Security package | The delivery’s component inventory, vulnerability response times, the disclosure process, file signatures, release notes. What’s already signed in the current release and what isn’t yet is listed in [Risks](/platform/risks/). | Covers the requirements of the security and procurement teams. | | Quality program | A set of documents for regression testing, sample files, speed and memory thresholds, an escalation process. | Reduces the risk of disputes after rollout. | ## Product tiers [Section titled “Product tiers”](#product-tiers) | Tier | What’s included | Who it’s for | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | [Evaluation kit](/start/glossary/) | The runtime, a sample application, a few sample documents, the quick start, and a list of known limitations. | For a CTO or architect running a first check. | | Limited pilot | One platform, one real working scenario, a narrowed capability profile. | Check whether the product fits and whether compatibility is good enough. | | Embedding kit | The public interface, types, a shell under your brand, adapters, and documentation. For documents, this is a contract and surface that work today; for spreadsheets, the public set is still taking shape, and its contents are fixed by the agreement — [what’s in it today](/sumsheet/embedding-api/). | A working integration into your product. | | Enterprise profile | The security package, version support and commitments, an update channel, acceptance before production use. | For enterprise customers and anyone deploying the product inside their own perimeter. | | Extended automation | Agents, the supported subset of VBA, Power Query and data connections, policy enforcement points. “Agents” means different things here: for documents, an agent uses the same commands as a person (there are 41), there is no separate interface for it, and it [only proposes](/sumdoc/host-api/); for spreadsheets, the “inspect, propose, apply” flow relies on the release’s operations, while the agent’s permissions, the audit contents, and the approval process are fixed by the pilot. | Complex data migrations, document-management, accounting, and resource-planning systems, analytical processes. | ## Licensing model [Section titled “Licensing model”](#licensing-model) The engine is licensed to the application that embeds it: not per seat, not per document, not per operation. | Stage | Terms | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Evaluation | Free: the full engine, real files. Working in the editor is not time-limited; automated processing without a key switches to quiet mode after 60 days — [key and operating modes](#key-and-operating-modes). | | Pilot | Two weeks on your corpus with written acceptance criteria; the report stays with you either way — [Pilot and acceptance](/platform/pilot/). | | Production use | An annual license for one embedding application. Updates and engineering support with a named response time are included in the price; deployment inside your perimeter, under your brand; users aren’t counted. | | Editors as a server | Server images of SumDoc and SumSheet inside your system: evaluation is free, production use is the same annual license for the embedding application. | | A \[\[var:node.product]] node with the editors inside | 90 days at full speed, then a key: \[\[var:pricing.node-50]] per month for up to 50 people, \[\[var:pricing.node-200]] for up to 200. Without a key, the node keeps working and keeps its data; only the automated paths slow down — export, conversion, transcription. | What the license covers: distributing the engine inside your application — in your perimeter or in your cloud, all engine updates during the term, engineering support with a named response time. The price depends on one thing: which application embeds the engine and how it is delivered. A written proposal — within one business day. ## Changes for your process [Section titled “Changes for your process”](#changes-for-your-process) You don’t pay for the right to open a file. You pay for adapting the tool to your process — with a deadline and a named owner. Our defects aren’t an order: a file that opens incorrectly, a lost edit, a crash — these are fixed for free, and the service level only sets the speed. | Class | Price | Deadline | Examples | | ----------------------------- | ------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | A — behavior settings | \[\[var:pricing.change-a]] | 1 business day | The default export format, page settings and fonts, the template set, features turned on and off, your logo and name on the editor surface, the interface language. | | B — connection to your system | \[\[var:pricing.change-b]] | 2–3 business days | Two endpoints of your system (“who am I”, “file by ID”), pass-through single sign-on, a save notification (webhook), a file naming rule, reverse proxy setup, a reversible rollback. | | C — engine behavior | \[\[var:pricing.change-c]] | up to 5 business days | Porting one macro or one Power Query source of a typical form, support for one DOCX or XLSX construct from your corpus, an export variant, automation of one operation. | | By estimate | from \[\[var:pricing.change-c]] | agreed in advance | Everything beyond class C: a set of macros, integration with a document management system without WOPI, a new data source, on-site work, a corpus audit before migration. | On-call — \[\[var:pricing.on-call-org]] per month per organization: a response within a business day, a file fix in the engine within five days, builds with fixes as they are ready. For one person — \[\[var:pricing.on-call-person]] per month. The price and deadline are named before work starts; if the deadline is missed, you don’t pay. A change arrives as a build or a setting, verified on our test bench with your file, with a note on what changed and how to roll it back; your originals and your system are not touched. ## Key and operating modes [Section titled “Key and operating modes”](#key-and-operating-modes) A person working in the editor — the editor window, the mobile app, the web sandbox — is never limited by a key. A key is needed only for automated processing: the command line, the developer kit, the API, and server-side export. | Mode | When | Limits | | ---------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Full | Working in the editor — always; automated processing with a valid key that covers the product. | No limits. | | Evaluation | Automated processing without a key, the first 60 days after the first launch on this machine. | No more than two operations in parallel, up to 1,000 documents per day, the “\[\[var:license.pdf-footer-mark]]” mark in the PDF footer. | | Quiet | Automated processing without a key after 60 days. | One document at a time, a 3-second delay per operation, 100 documents per day, the same mark in the PDF. | There is no refusal in quiet mode: parallel requests wait their turn, and an exhausted daily quota waits for the next day. A key covers the products named in it and remains valid for another 30 days after it expires. ## For developers [Section titled “For developers”](#for-developers) Environment variables for automated processing: | Variable | What it does | | ------------------------------------ | -------------------------------------------------------------------------------------------------------- | | `SUMOFFICE_LICENSE` | The key as a string; `SUMOFFICE_LICENSE_FILE` — the path to the key file. | | `SUMOFFICE_SESSION_KIND=interactive` | Declares an interactive session — for the desktop shell that starts the processor on behalf of a person. | | `SUMOFFICE_LICENSE_QUOTA_WAIT=fail` | Instead of waiting for the quota, return exit code 75 — for a service with its own queue. | Concurrency in quiet mode is held by locks: the second request waits rather than being refused. ## What’s next [Section titled “What’s next”](#whats-next) * How verification works before the contract — [Pilot and acceptance](/platform/pilot/). * What’s in the delivery — [What the delivery includes](/platform/delivery/). * To request a written proposal or a pilot — [contact us](/start/contact/). # What the delivery includes > Exactly what you get: engines, a ready-made interface, server images, mobile kits, the capability matrix, the evaluation kit, and the operations package. You do not get “the editor’s source code” but a developer kit together with a runtime: the contract, examples, the capability matrix, and acceptance scenarios. This means the integration rests on fixed commitments, not on reading someone else’s code. | What’s included | What it is | What this gives you | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Document editor inside an application | Surface Host — a local SumDoc service in Rust with a built-in interface; it runs in your program’s window and listens only on a local address. | A DOCX editor inside your own desktop program, with no dependency on Electron. | | Document editor in the browser | The SumDoc server image: each user gets their own core process with their own document. Published separately from the desktop installer — an image on Docker Hub and an archive in the release directory. | A DOCX editor in the browser inside your web product — [how it works and where to get it](/sumdoc/webhost/). | | Spreadsheet processor in the browser | The same kind of server image for SumSheet: a process per user with its own copy of the workbook, sign-in through your system, file export and delivery. Published separately from the engine packages. | An XLSX editor in the browser when the core computes on the server — [the server path](/sumsheet/server/). | | Mobile apps and the viewer kit | Ready-made apps for iPhone, iPad, Android, and the Mac App Store. A free viewer kit for Android and iOS — viewing only, for DOCX, DOCM, XLSX, and XLSM — ships under the same version number as the store build, with a checksum. Editing inside your app is the editing kit, licensed per app. | A document or spreadsheet on the phone without your own server and your own screens — [phone and tablet](/start/mobile/). | | Spreadsheet engine packages | SumSheet builds for the desktop app and for the browser, the operation contract adapter, workbook and session state. The [embedding examples](/sumsheet/examples/) are assembled from these packages; they are not published to the public npm registry. | Formulas, history, import and save for spreadsheets — and the choice of where the core runs. | | A surface under your brand | A ready-made interface: the document canvas or the spreadsheet grid, dialogs, commands, theme, and language. | A working editor inside your product without building an interface. | | A public interface | Stable methods for opening, executing, subscribing to events, saving, and closing; types, errors, and declared capabilities. | An integration that does not depend on internal names in the code. | | Application adapters | Examples for a window inside a desktop program, for the browser, for local exchange, and for working with storage. | A short path from the first try to a pilot. | | Capability matrix | Format × runtime × operation × read, edit, save, and markup preservation × limitations. Part of it is open already: [13 spreadsheet formats](/reference/sumsheet/formats/) and [what you can do with each file in documents](/sumdoc/overview/#which-files-it-works-with). | “We support the format” becomes a verifiable commitment. | | Evaluation kit | Examples, sample documents, an end-to-end path on a real file, the expected result of each step, notes on logging and security. | Your engineer opens their own document in 30–60 minutes, or builds a technical prototype. | | Architecture specification | A document for architects: protocol, session lifecycle, security, versioning, deployment, and acceptance. Issued together with the evaluation kit. | The integration can be designed before the first call — [where to start a pilot](/sumdoc/handoff/). | | Operations package | Signatures of delivery files, component inventory, the vulnerability handling process and response times, migration notes between versions, release and update rules. Which signatures exist in the current release and which do not yet is listed under [risks](/platform/risks/). | A runtime that a corporate operations team will accept. | What isn’t part of the delivery Source code and unlimited access to all internal commands: the set of capabilities is defined by the chosen profile. Instead — a named public developer kit with a fixed lifecycle, support period, long-term version support, security requirements, and acceptance scenarios. For documents this kit works today — it is the session contract and the surface. For spreadsheets it is still being separated from the internal contract, and its contents are fixed by agreement, not implied: [what is in it today](/sumsheet/embedding-api/). ## For developers [Section titled “For developers”](#for-developers) * Server images: `docker pull hissih/sumdoc-webhost:latest` for documents and `docker pull hissih/sumsheet-webhost:latest` for spreadsheets. The image archive is in the `webhost/` folder of the release directory — `https://dl.layers.md/sumoffice/sumdoc/release/latest/webhost/` and `https://dl.layers.md/sumoffice/sumsheet/release/latest/webhost/` — together with `INSTALL.md` and `SHA256SUMS`. * Spreadsheet engine packages — `@sumsheet/*`; the viewer kit for the phone ships with a sha256 checksum. * Where to start checking: [installing SumDoc](/sumdoc/install/) and the [quick start](/sumdoc/quickstart/), [installing SumSheet](/sumsheet/install/) and the [quick start](/sumsheet/quickstart/). # Embedding modes > Eight ways to connect the platform—from a ready-made surface to a server inside your perimeter and a preview without an editor: when to choose each one and what is mandatory in all of them. You don’t have to adopt the whole platform at once. You can start with a ready-made surface inside your product and then deepen the integration—to headless operation, to a separate process or to the core right in the browser. The meaning of a command doesn’t change along the way: it’s defined by the contract, not by the way data is transported. Two things matter for the decision: where your product lives and where the data must stay. The mode is chosen by these two questions. | Mode | When to choose it | Readiness and boundaries | | ----------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | SumDoc inside a desktop application | You need a full DOCX editor inside your Windows or macOS program. | Verified on macOS; acceptance on Windows must be run separately. The reason is not a formality: on macOS text width is measured by the system font engine, on Windows and Linux by a portable one, so identical pagination across systems is not promised. That is exactly what to check at acceptance—on your own documents and your own fonts. | | SumDoc in the browser | Your product lives on the web, and the user doesn’t need to install anything. | Works. The document is computed by the core on your server, one process per user. Several people edit one document at the same time: others’ input is visible immediately, the one who opened it first writes to the file, the rest are co-editors or observers as chosen at sign-in—[the editor in the browser](/sumdoc/webhost/). | | SumDoc headless | Batch processing, services, and agents that don’t need a screen. | Works as the session protocol; which part of it becomes public is agreed separately. | | SumSheet in the browser | Embedding in a web product when data must not leave the browser. | Works. The core computes in the page’s memory and itself picks the fastest build the browser allows; if it didn’t take a faster one, it names the reason. The fastest, multithreaded build requires configuration on your site and a separate delivery—[the core in the browser](/sumsheet/wasm/). | | SumSheet as a separate process | Offline operation, local files, full speed. | Works. The process must be monitored, shipped with updates and shut down correctly—[a separate core process](/sumsheet/native/). | | Hybrid mode | A web interface, but with access to the file system and OS rules. | You need a secure channel between the interface and the core and a well-thought-out window lifecycle. | | A server inside your own perimeter | Centralized processing, agents, pipelines. | A separate production architecture: access checks, isolated sessions, quotas and operations tooling—[the processor on a server](/sumsheet/server/). | | Preview without an editor | You need thumbnails, read-only pages or PDF from DOCX and XLSX, but no editor. | Works. One container with the SumDoc and SumSheet cores; the file is erased after the response, and no network is needed once the image is downloaded. PDF from a workbook is not produced yet, presentations and ODS are not accepted—[preview without an editor](/platform/preview/). | ## What’s required in every mode [Section titled “What’s required in every mode”](#whats-required-in-every-mode) * One open document per process — the simplest and safest isolation for a pilot. * The application learns the contract version before it shows the interface or sends the first command. * Tokens, addresses, credentials, document text, and its source markup don’t go into logs by default. * Closing releases everything: listeners, connections, background threads, files and child processes. * An unknown command or capability is never executed silently: work stops, or a refusal with a reason comes back. ## For developers [Section titled “For developers”](#for-developers) * How each mode works: SumDoc—[platforms and deployment](/sumdoc/deployment/); SumSheet—[the core in the browser](/sumsheet/wasm/), [a separate core process](/sumsheet/native/), [the processor on a server](/sumsheet/server/), [phone and tablet](/sumsheet/mobile/). * SumDoc desktop mode: your application plus a local service per document; HTTP and WebSocket on the local interface only; a WebView2 or WKWebView window. Headless mode: JSON lines over standard input/output, or WebSocket with a token. * The multithreaded SumSheet build in the browser is enabled only when two conditions hold at once: the COOP and COEP isolation headers on your site and SIMD support in the browser; without either of them the core takes a simpler build and names the reason—[the core in the browser](/sumsheet/wasm/). * For the processor, the contract version is reported by the greeting line—it is read first; in the browser there is none, and the version is requested from the session with a `contract_version()` call—[SumSheet runtimes](/sumsheet/environments/). * The success flag in the response envelope is not the whole story: for a document edit, the outcome is named in a separate field—[how to read a response](/sumdoc/envelope/). # What's promised, and what isn't > Behind general phrases like “full compatibility” and “white-label delivery”: what's promised and verifiable, and what's fixed separately. Plus the questions worth answering before you start integrating. Office engines are usually described in general words: “an Office replacement”, “full compatibility”. Such words can neither be verified nor fixed in a contract. Below is what stands behind each of them in the case of SumOffice: on the left the familiar wording, on the right what is actually promised and verifiable on your files. | General phrasing | What’s actually promised | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A replacement for Word and Excel. | An embeddable office processor for your product: editing DOCX and XLSX files, saving with a reopen check, automation, and an interface under your brand. | | Full compatibility with Microsoft Office. | Matching behavior on an agreed set of your documents, for the listed capabilities, and within the bounds of the declared matrix. | | We support XLSX and DOCX. | For every format and every operation, it’s recorded separately: whether it’s read, edited, saved, and whether unsupported markup is preserved. This is already public: [13 spreadsheet formats](/reference/sumsheet/formats/) and [what you can do with each file type in documents](/sumdoc/overview/#which-files-it-works-with). | | We have VBA. | Its own runtime for an agreed subset: inspect the project, see the plan and the changed cells before running, run with a limit, apply or roll back. What is not supported—COM, external libraries, certain statements—is rejected with a message rather than faked; the contents of the subset are fixed in the matrix. | | We have Power Query. | Queries are read, saved without loss, and refreshed by its own M language engine: sources, steps, preview, load, refresh. An unsupported source gets an explicit refusal with a migration path rather than a silent failure; the list of supported sources is fixed in the matrix. | | We’re the fastest. | Instead of a slogan, measurements on your own documents: typical and worst-case time, memory, the amount of data loaded, saving and reopening. | | White-label delivery. | You own the shell, the brand, sign-in, storage, and processes; SumOffice is responsible for the meaning of the document and the spreadsheet. | | An agent edits the document. | An agent works through the same operations contract and history as a human: inspect, plan, preview the result, get confirmation, apply or roll back. | ## The platform in brief [Section titled “The platform in brief”](#the-platform-in-brief) ## Questions before you start [Section titled “Questions before you start”](#questions-before-you-start) * Which operating systems, which technology is your application built on, and which embedding method do you need at the first stage? * Which three to five of your real documents will decide whether the product fits? * Which ten user actions need to work without Microsoft Office? * Which of these are critical: comments, tracked changes, tables, fields, headers and footers, formulas, charts, pivot tables, Power Query, VBA? * Where are documents stored: on the computer, inside your perimeter, in the browser, in a document-management or accounting system, in the cloud? * What are the security requirements: where the data physically resides, leak control, logging, the delivery inventory, signatures, audit? * Do you need agents, and which operations are they allowed to read, propose, and apply? ## Next [Section titled “Next”](#next) * Verify what’s promised on your own files — [Pilot and acceptance](/platform/pilot/). * What’s locked in by the contract — [Commercial packaging](/platform/commercial/). * What isn’t covered yet — [Risks and honest boundaries](/platform/risks/). * Start small — [early access request](/start/beta/). # Feature parity with Word and Excel > How to state parity correctly: seven levels — from everyday scenarios to operations — and how to prove each one. Nobody has full parity with Word and Excel except Microsoft Office itself. A promise of “feature parity” without qualification means nothing and can’t be verified. That’s why parity is broken down into tiers—and at every tier there’s a way to check on your own files. | Tier | What it means | How it’s proved | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | By scenario | The user performs their everyday actions without switching to Microsoft Office. | An agreed acceptance scenario inside your application. | | Format openability | DOCX, XLSX, XLSB, ODS and CSV open in the chosen runtime. Opening isn’t the same as editing and saving: these are separated by row—[spreadsheet formats](/reference/sumsheet/formats/), [what you can do with each file in documents](/sumdoc/overview/#which-files-it-works-with). | Open the entire agreed set of documents and review every warning and refusal. | | The editing corridor | The agreed capabilities work correctly: text, tables, formulas, formatting, comments, sheets, charts. | Compare the document’s meaning before and after editing, for every capability on the list. | | Save | A saved file reopens without losing its meaning or structure. | Reopen it in a new process, ideally twice, and separately verify the “saved here, opened in Word or Excel” round trip. | | Preservation of the unsupported | What the editor doesn’t understand is preserved unchanged, or explicitly flagged. | Compare the file’s contents before and after, including the relationships between parts. | | Automation | Macros, queries, and agents work within the supported subset; everything else is recognized and explained. | A capability matrix, explicit refusals instead of silent errors, an action log. | | Operations | Offline operation, on-premises installation, security, updates, and the lifecycle meet enterprise deployment requirements. | A security checklist, full resource release on shutdown, the delivery inventory and signatures — what’s already there today is listed in [Risks](/platform/risks/). | ## Why this is stronger than the usual “we support XLSX/DOCX” [Section titled “Why this is stronger than the usual “we support XLSX/DOCX””](#why-this-is-stronger-than-the-usual-we-support-xlsxdocx) * What matters to the customer isn’t a list of file extensions, but that nothing was lost after saving. * What decides a migration are the specifics: data queries, macros, links to other workbooks, charts, pivot tables, styles, comments, tracked changes, headers and footers, and fields. * Whoever embeds the editor in their product cares about more than looks: the lifecycle, memory consumption, full resource release on shutdown, update compatibility and observability. * The capability matrix turns an argument into a verifiable agreement: what is read, what is edited, what is saved, what is preserved as-is without parsing, and what is rejected. The matrix doesn’t use free-form language. The spreadsheet delivery contains a closed list of eight states, and every cell gets one of them: | State | What it means | | ------------------------- | ---------------------------------------------------------------------------------------------------------- | | Absent | This part wasn’t present in the workbook under test. | | Not documented | This part is on the list, but the product can’t recognize it yet — and doesn’t pretend that it can. | | Detected, not interpreted | Its presence is detected, but the product doesn’t assign it meaning and doesn’t promise to preserve it. | | Preserved only | The part passes through open and save as opaque data: it won’t be lost, but it won’t be understood either. | | Cached value only | What’s shown is whatever Excel wrote; the product doesn’t promise a live recalculation. | | Partial | There’s live behavior, but coverage is narrow, and that’s stated outright. | | Blocked by policy | The part is recognized, but running it is deliberately blocked — by a product rule or a security policy. | | Fully live | Its meaning is modeled and kept live, without relying on cached values. | The difference between “preserved only” and “cached value only” is the boundary people usually argue about: in the first case the part of the workbook comes back unchanged, in the second you’ll see a number, but it wasn’t recalculated by us. A state is assigned not to the workbook as a whole but to its parts. The list of parts is closed too—ten families: | Workbook part | What it includes | | ----------------------------- | ------------------------------------------------------------------------------------------------------ | | Macros | Automation built into the workbook: VBA and the like. | | Add-ins | Functions and commands that come from add-ins. | | External data | Connections and refreshable queries. | | External references | References to other files and workbooks. | | Names and hidden dependencies | Named ranges, hidden areas—everything that affects the workbook’s meaning without appearing on screen. | | Tables | Structured tables, their styling and behavior. | | Pivots and the data model | Pivot tables, their caches, slicers and the data model. | | Protection and trust | Protection flags and parts restricted by trust rules. | | The import/export round trip | Parts where what matters isn’t behavior but import accuracy and preservation on export. | | Provenance and diagnostics | Parts that explain why content was preserved as-is, blocked, or shown from a cache. | The matrix is the intersection of the two lists: every workbook part has its own state. The question “do you support macros” turns into “what state do macros have in my workbooks”, and that one has a verifiable answer. ## What to measure with [Section titled “What to measure with”](#what-to-measure-with) * 41 commands of the SumDoc document session—for developers: [Session Protocol reference](/reference/sumdoc/session-protocol/). * 208 operations in the SumSheet contract; which of them the core of the latest release accepts is stated in the [Compute Contract reference](/reference/sumsheet/overview/). Take the release as the yardstick for acceptance: what is described but not yet in the build can’t be verified on your workbooks. * What’s available today, and what’s part of the pilot — [SumDoc readiness and boundaries](/sumdoc/status/) and [SumSheet strengths and trade-offs](/sumsheet/tradeoffs/). # Pilot and acceptance > How to prove the promise: what is verified, the two-week pilot plan, and what the go or no-go decision is based on. A pilot proves real embedding, not a presentation: your document opens inside your application, is edited, saved, and reopened without loss. The go or no-go decision is made against written criteria, and the report stays with you either way. ## What is verified [Section titled “What is verified”](#what-is-verified) | What we verify | What counts as passed | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opening | A real document or workbook opens inside your application; no separate editor window appears. The declared capabilities are visible. | | Editing | The user performs the agreed edits; each edit creates one history entry, and the application learns about unsaved changes. | | Saving | The file is returned to your application; the right to save is declared explicitly. | | Reopening | The saved file reopens from a cold start without loss of meaning or integrity — for documents and for spreadsheets. | | Events | The application receives the open (`ready`), change (`dirty`), save (`saved`), error (`error`), and close (`unmounted`) events; events of a white-label delivery are by agreement. For spreadsheets, the event contract is fixed and versioned, but the part that implements it isn’t in the release yet: you can write code against the names today, but you can’t run it, and this row can’t be verified for spreadsheets during the pilot ([what the kit includes](/sumsheet/embedding-api/)). | | Security | The token and credentials don’t leak, the service listens only on the local address, document content doesn’t end up in logs; the policy is checked before opening, saving, and any network call. | | Resource release | After closing, no processes, connections, or background tasks remain. | | Performance | Startup, opening, editing, recalculation, saving, and memory on the agreed classes of documents and workbooks. | ## Pilot plan: two weeks [Section titled “Pilot plan: two weeks”](#pilot-plan-two-weeks) A pilot is a structured two-week verification on your document corpus with written acceptance criteria: what opens, what survives the “open — save — open” round trip, and what performance you see. | Stage | Duration | Result | | -------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Assessment | 1–2 business days | Choice of platform and server side, key scenarios, document corpus, acceptance criteria, security requirements, and the business owner on your side. | | Prototype and measurements | by the end of the second week | Opening, editing, saving, and reopening real DOCX and XLSX files from your corpus inside your container; performance measurements against the acceptance criteria. | | Decision: go or no-go | 1 meeting at the end of the second week | A report against the acceptance criteria, the final list of capabilities, the list of work before production use, a commercial estimate, and the expected commitments on availability and version support period. | | Work for your process | after the decision, by estimate | Styling under your brand, a storage adapter, single sign-on and audit, events, selected product routes. These are not part of the pilot: they are changes for your process, with a price and a deadline named in advance — [commercial packaging](/platform/commercial/). | ## For developers [Section titled “For developers”](#for-developers) * What to give your engineers and in what order to read it — [How to start a pilot](/sumdoc/handoff/). * The list of checks before a pilot — the [SumSheet checklist](/sumsheet/checklist/) and the [SumDoc checklist](/sumdoc/diagnostics/). * Event names: for documents — [SumDoc embedding](/sumdoc/embedding/), for spreadsheets — [the embedding kit](/sumsheet/embedding-api/). The evaluation kit is described in the [glossary](/start/glossary/). # Preview without the editor > One container with the SumDoc and SumSheet cores: a thumbnail, pages for reading, and PDF from DOCX and XLSX—what it gives you, the limits, and the requests for a developer. Not every place in a product needs an editor. A file list needs a thumbnail, a card needs pages for reading, a “download” button needs a PDF. For that there is a separate preview container: it turns DOCX and XLSX into an image, pages, or PDF and stores nothing. For the business this means: you can show a document in your product without the editor and without sending files outside. ## What it does [Section titled “What it does”](#what-it-does) * A thumbnail of the first page of a document or the first sheet of a workbook. * All pages of a document or all sheets of a workbook in a form ready for reading in the browser. * A PDF of the document. PDF from a workbook is not produced yet: the spreadsheet core does not print to PDF, and such a request gets a refusal with a reason. Inside are the SumDoc and SumSheet cores and fonts with Office metrics, so pages break the same way as in the editor. The response reports whether everything was rendered: how many pages out of how many, whether there are scripts missing from the built-in font, and how many formulas are shown empty because the workbook holds no values for them. ## Limits [Section titled “Limits”](#limits) * Presentations are not accepted—until the third editor appears; ODS is not supported yet. An unknown format gets a refusal with a clear message. * The service does not accept files larger than 50 MB; the limit can be changed. * The request directory is wiped right after the response; the service makes no outbound calls, and no network is needed after the image is downloaded. * Viewing is free; production use is under the license for the embedding application—[commercial packaging](/platform/commercial/). ## For developers [Section titled “For developers”](#for-developers) Start: ```sh docker run -d -p 8099:8099 hissih/sumoffice-preview ``` One container, about 224 MB. Allow roughly 250 MB of RAM for each document processed concurrently. The file size limit is set by the `PREVIEW_MAX_MB` environment variable. | Request | What it returns | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `POST /thumb?w=320` | A PNG of the first page of a document or the first sheet of a workbook as a grid of values. The width `w` is from 64 to 2000 pixels; a value outside the range is clamped to the nearest bound. | | `POST /pages` | Self-contained HTML: all pages of a document or all sheets of a workbook as tables. | | `POST /pdf` | A PDF of the document. For a workbook—a 415 refusal with a reason. | | `GET /health` | A check that the service is alive. | The file is passed as the `file` field of a `multipart` form or as the raw request body—then the file name is given by the `?name=report.docx` parameter or the `X-File-Name` header. An unknown format gets a 415 refusal. ```sh curl -F file=@report.docx http://localhost:8099/thumb?w=320 > thumb.png curl -F file=@report.docx http://localhost:8099/pages > report.html curl -F file=@report.docx http://localhost:8099/pdf > report.pdf curl -F file=@book.xlsx http://localhost:8099/pages > book.html ``` Response headers—they are used to decide whether to show the result as complete: | Header | What it means | | ----------------------------------------- | --------------------------------------------------------------------------------------- | | `X-Preview-Pages` | How many pages the document has according to the PDF. | | `X-Preview-Coverage`, `X-Preview-Partial` | How many pages were rendered out of how many; `Partial: true` if fewer than in the PDF. | | `X-Preview-Scripts-Outside-Font` | Scripts missing from the built-in font—they may have rendered incorrectly. | | `X-Preview-Sheets`, `X-Preview-Cells` | How many sheets and cells the workbook has. | | `X-Preview-Uncomputed-Formulas` | How many formula cells are shown empty: the workbook holds no values for them. | ## Next [Section titled “Next”](#next) * The other embedding modes—[Embedding modes](/platform/deployment/). * The same container path, but with the editor—[the SumDoc editor in the browser](/sumdoc/webhost/) and [the SumSheet processor on the server](/sumsheet/server/). # Your own office instead of Microsoft Office > DOCX and XLSX editors inside your product and your perimeter, under your brand: what this gives a company, what already works, and how to verify it in an hour. Business documents still live in DOCX and XLSX: contracts, estimates, deliverables, and reports. Some of them are not documents but applications: formulas, macros, Power Query, form controls. A workbook that calculates is a program, and leaving Microsoft means keeping it running. The choice is usually between bad options: shipping documents to someone else’s cloud, or moving people to an editor that cannot be embedded in your own processes. **SumOffice is an independent office platform whose engines embed in your product.** Not another office suite next to yours, but a document and spreadsheet editor inside it: under your name, inside your perimeter, with your access rights and your storage. The platform has no ties to Microsoft. ## What you get instead of someone else’s office [Section titled “What you get instead of someone else’s office”](#what-you-get-instead-of-someone-elses-office) | Today, with someone else’s office | With SumOffice | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | The document opens in an external application or someone else’s cloud | The document opens inside your product; files never leave your perimeter | | The editor carries someone else’s name and interface | The editor carries your name, your colors, and your navigation | | Permissions and audit live separately from the document | Your system checks permissions; every action goes through the contract | | “Supports DOCX” is a promise in words | A capability matrix: what’s read, what’s edited, what’s preserved without loss | | Automation is macros nobody knows about | The agent works through the same contract as a person: preview, confirmation, rollback, log | | A vendor update can break your integration | A versioned contract and a compatibility period, locked in by the agreement | ## Leaving Microsoft: four steps [Section titled “Leaving Microsoft: four steps”](#leaving-microsoft-four-steps) Not a feature list, but a check your team will run. Each step is a real file on a real server, and the result says outright what is not there yet. 1. **Upload a workbook** — [on the check page](https://view.sumoffice.com/check/) or send it to the [check bot](https://sumoffice.com/bots) in Slack or Telegram. Nothing in it is executed; the file is deleted after 24 hours. 2. **Read the report**: every macro with its route, functions known and unknown to the engine, data sources — as “N of M”. 3. **Open the same workbook in the browser** on our server: formulas recalculate, macros follow their routes, nothing is installed. 4. **Save and open in Excel**: the VBA project byte for byte, values in place. A macro or a Power Query source the engine does not carry yet is a change for your process: \[\[var:pricing.change-c]] per item, the whole corpus by estimate, price and timeline stated before work starts — [Commercial packaging](/platform/commercial/#changes-for-your-process). ## You can try this right now [Section titled “You can try this right now”](#you-can-try-this-right-now) Not a presentation and not a screen recording, but a working program: both editors open right on the site, in the browser, with nothing to install. If the demo environment is down at that moment, a snapshot takes the place of the frame — and the page says so outright. The SumDoc document editor A two-page contract: headings, lists, a table with dates and an amount. Open it, edit a paragraph — the document lives in your own sandbox. [Open the live example →](/sumdoc/demo/) The SumSheet spreadsheet processor An office-equipment budget with formulas. Change a quantity or a price — the core recalculates the totals, the shares, and both sums, not the page layout. [Open the live example →](/sumsheet/demo/) For developers, there are worked embedding projects with full code next to it: [twenty-three examples for spreadsheets](/sumsheet/examples/) — from a minimal sheet to a million-row workbook, collaboration, and links between workbooks — and [a project for documents](/sumdoc/examples/). ## Why this isn’t a wrapper around someone else’s editor [Section titled “Why this isn’t a wrapper around someone else’s editor”](#why-this-isnt-a-wrapper-around-someone-elses-editor) The meaning of the document belongs to its own core: it parses the file, computes layout and formulas, keeps the history, and writes the result back. The interface only shows and asks — it has no copy of the document of its own. For you this means the result is the same in the desktop app and in the browser, and that one side is responsible for it. * **A verifiable boundary.** 41 document session commands and 208 spreadsheet contract operations are exposed, each described in the reference, and the reference is checked against the code on every documentation change. Which operations the core of the latest release accepts, and which are described but not yet in the build, is stated separately. For developers — the [SumDoc reference](/reference/sumdoc/overview/) and the [SumSheet reference](/reference/sumsheet/overview/). * **Formats are named one by one.** 13 spreadsheet formats, including XLSX, XLSB, XLSM, ODS, and CSV — with a [matrix](/reference/sumsheet/formats/) that says for each what can be opened, what can be edited, and where it can be saved. The document side handles DOCX and exchanges **eight more formats**: PDF, ODT, flat ODT, RTF, HTML, plain text, EPUB, and FB2 — all in both directions except PDF, which is print only. [Which files it works with](/sumdoc/overview/#which-files-it-works-with). * **Refusal instead of silent corruption.** An unsupported operation gets an explicit refusal with a reason **before** the file changes. There is no such thing as a half-written document: the file is published in one atomic action, and the editor refuses to overwrite an edit made by someone else. * **Preserving what’s not understood.** Parts of the file the editor doesn’t parse carry over into the new file as-is, instead of disappearing on save. * **Speed you can see, not just a promise.** A [million-row sheet](/sumsheet/examples/stress/) is open right on the site: scroll it, and it shows you the frame cost itself — typical, worst-case, and whether it stayed within budget. The measurement runs on your machine, not in our presentation. * **Works without a network and without a cloud.** A desktop app, a window inside your program, the browser, a server inside your perimeter, a phone — the same contract in every environment. The core never calls out; the only outbound channel is in the ready-made apps — the support assistant with error reports, and it is described under [security](/platform/security/). The SumDoc and SumSheet mobile apps are released for iPhone, iPad, and Android, and for macOS. For embedding in your own app there is a free viewer kit for Android and iOS — the same engine as in the store builds, under the same version number; editing inside your app is the editing kit, licensed per app ([phone and tablet](/start/mobile/)). ## What we compare ourselves to [Section titled “What we compare ourselves to”](#what-we-compare-ourselves-to) With Word and Excel — there’s nothing else to compare against. They’re what’s already on your people’s desks, your contracts and estimates are written in them, and they’re exactly what the result will be measured against. But the comparison isn’t about the number of buttons. Office is a finished product for a workstation; you buy it so a person can open a file. You buy SumOffice so that **an office appears inside your product**: not an application alongside it, but an engine inside it, under your own name. Exactly what the product does with the file is broken down by task: the [SumDoc capability map](/sumdoc/capabilities/) for documents and the [map next to Excel](/sumsheet/atlas/) for spreadsheets. What parity means and how it’s confirmed — [Feature parity](/platform/parity/). ## How this is verified at your end [Section titled “How this is verified at your end”](#how-this-is-verified-at-your-end) We don’t ask you to take our word for it. Verification happens on your own files and inside your own perimeter, in steps known in advance: 15 minutes The core responds, your DOCX is open, a paragraph is changed and saved as a separate file. Step by step, for a developer — in the [quick start](/sumdoc/quickstart/). 30 minutes The same document, but now inside your application: the editor in your window, editing, saving, events. The steps are in [How to start a pilot](/sumdoc/handoff/). 2 weeks The full pilot: a check on your document corpus with written acceptance criteria, measurements, and a “take it or not” decision; the report stays with you either way. Stages and timelines — in [Pilot and acceptance](/platform/pilot/). What the contract locks in — the capability profile, the platform matrix, acceptance scenarios, support terms, and security commitments — is gathered in [Commercial packaging](/platform/commercial/). ## What’s next [Section titled “What’s next”](#whats-next) [Submit an early access request](/start/beta/)Three fields. We will send the builds and tell you outright what already works and what is still rough. [What you get: in short](/platform/story/)The product formula in three parts: what you bring, what the platform does, what comes out. [Risks and honest boundaries](/platform/risks/)What isn't covered yet, and what covers it. No rollout conversation is complete without this page. [What embedding gives you that Office doesn't](/platform/advantages/)Not “we're better”, but a list of the places where embedding gives you something a ready-made office suite can't. [What's promised, and what isn't](/platform/messaging/)The claims we're ready to defend during a pilot, and the ones we deliberately avoid. [VBA, Power Query, and agents](/platform/automation/)Automation without losing control: a supported subset, a Power Query ladder, and agent work as a single transaction. [What's coming next](/platform/roadmap/)Where the platform is heading, and what will arrive before the rest. # Risks and honest boundaries > What can't be promised without a separate agreement, and which limits need to be spelled out in advance. Promising “full Office” without criteria is easier, but such a promise can’t be verified. So this page names what’s still open and what closes it. Without this page, a conversation about rollout is incomplete. | Risk or open question | Why it matters | What covers it | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What will be in the public interface | There are more internal capabilities than can be declared public and then supported for years. | A locked public interface, types, and versioning rules. | | Fidelity of round-tripping | A file opening doesn’t yet mean it will come back from the editor without loss. | A matrix of critical documents and capabilities, before-and-after file comparison, a reopen check. | | Archival PDF/A | For archives and legal or government records management, this is a condition of admissibility, and plain PDF isn’t enough there. | Plain PDF export works, including with embedded fonts; PDF/A-1b readiness is checked with a separate command, and export to that format itself is still closed and runs through your own verification program — [what you can do with each file type](/sumdoc/overview/#which-files-it-works-with). | | VBA | Security requirements and incomplete compatibility clash with expectations that it “just works”. | A matrix of supported calls, a list of refusal kinds, security rules, and a ban on changing the document silently. | | Power Query | Rollout most often runs into exactly this: queries, connections, and the data model. | Recognition and preservation first; refreshing and editing queries as a separate stage; acceptance by comparing files. | | Speed claims | The market is already oversaturated with slogans like “ten times faster”, and arguing with slogans is pointless. | A reproducible benchmark on your own documents, fixed hardware, thresholds for typical and worst-case time. | | Confirmation on every system | Verification on one system doesn’t automatically carry over to the others. | Separate acceptance on every declared system and in every embedding method. For documents, look at pagination first: text width is measured by the engine of the system where the core runs — the system engine on macOS, a portable one on Windows and Linux. Spreadsheets don’t have this cause: SumSheet doesn’t use system font engines; widths are taken as declared in the workbook itself. | | A server with many clients at once | Working in a desktop application doesn’t carry over to a cloud service. | A separate architecture: quotas, access checks, a task queue, isolating clients from each other, observability. | | Packaging and signing | An unsigned file won’t pass enterprise deployment. | Not everything is signed yet, and it differs by product — the list is below. Wherever there’s no signature, checksum verification remains; how to check is shown on the installation pages for [SumDoc](/sumdoc/install/) and [SumSheet](/sumsheet/install/). | | Version support | You depend on how long the version your product is built on stays supported. | A support period, deprecation rules, migration guides, an escalation process. | ## What is signed today [Section titled “What is signed today”](#what-is-signed-today) * **SumDoc.** The macOS app is signed with a Developer ID certificate and notarized by Apple; the Windows installers carry no signature. * **SumSheet.** The app in the `.zip` archive is signed and notarized — verified on a downloaded build: the system answers `accepted` and `source=Notarized Developer ID`; the `.dmg` image from the same folder carries no notarization. The Windows installers are signed with a **test certificate**, “SumOffice Test Signing (DEVELOPMENT ONLY)” — the system will warn about an unknown publisher; this signature isn’t confirmed by the release evidence, so check it on the downloaded file yourself. * **Both products on Linux.** The `deb` and `AppImage` packages have a detached `.asc` signature next to them; `rpm` doesn’t. ## Decisions to make before you start [Section titled “Decisions to make before you start”](#decisions-to-make-before-you-start) * Your target operating systems, your application’s technology, the embedding method, and the deployment boundary. * A dozen critical user actions and three to five real documents. * Requirements for comments, tracked changes, tables, drawings, fields, sections, and headers and footers. * Requirements for formulas, charts, pivot tables, external references, Power Query, macros, and data connections. * What agents are supposed to do, what permissions they’re given, what goes into the audit trail, and who approves their actions. * Where files come from and where they’re saved, how backups and recovery work, how leaks are caught, what gets written to logs, and where performance metrics go. * What availability commitments are needed, how many years a version must be supported, how often updates ship, who’s responsible for rollout, and how vulnerability handling works. ## Next [Section titled “Next”](#next) * How these boundaries are verified on your documents — [Pilot and acceptance](/platform/pilot/). * What the contract covers — [Commercial packaging](/platform/commercial/). * In what order the rest gets covered — [What’s coming next](/platform/roadmap/). * Start small — [early access request](/start/beta/). # What's coming next > What's not yet in the platform, in what order it will appear, and what each piece of work gives you. Plus a short formula for the offer. Part of the platform hasn’t been brought to delivery yet, and it’s more honest to say so directly. Below is the order of work and what each piece will give you. You can plan a rollout by this list: it says what will appear before the rest. | Order | What’s being built | What this gives you | | ----- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | A single capability matrix | One list for both products: what opens, what can be edited, what’s preserved without loss, and where the boundaries are. You can check it before the pilot, not after. | | 2 | Evaluation kit | Both surfaces, a sample application, a quick start, and a correct result known in advance — to compare with what you got. | | 3 | A set of documents for comparison | Twenty to fifty real files, run through us and through other office suites. The difference shows up in the documents, not in promises. | | 4 | What happens with macros | Which calls are supported, which are deliberately rejected, under what security rules, and what to do with the ones that aren’t supported. | | 5 | What happens with data queries | On real workbooks: what’s recognized, what’s preserved on write, what you can view, what you can refresh, and what you can create from scratch. | | 6 | Stable names and versions | Package and type names will stop changing between releases, and versioning rules will tell you in advance whether an update will break your build. | | 7 | A kit for the security team | The delivery inventory, signatures, the update and rollback process, vulnerability-fix timelines, and telemetry rules. | ## Where the conversation starts [Section titled “Where the conversation starts”](#where-the-conversation-starts) The platform’s formula fits in one sentence: your product plus SumOffice’s engines equals your own office platform. The detailed account exists as a foundation, so the short materials don’t promise more than they should. ## The final formula of the offer [Section titled “The final formula of the offer”](#the-final-formula-of-the-offer) | What you get | What the end user gets | What the security team gets | | ------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Libraries and cores for documents and spreadsheets | Editing documents and spreadsheets inside the product they already use | A versioned call contract, a delivery inventory, and signatures — to the extent they exist in the current release (the seventh row of the queue above covers what’s still missing from this kit) | | A ready-made interface — keep it as is, or replace it with your own | The work never leaves the application they already use | Document content never goes into logs — this is a condition of delivery; policies, leak control, audit | | Adapters and scaffolding for your stack | Real documents open and save on day one | The lifecycle under control, acceptance that verifies no leaks | | A capability matrix and a set of acceptance documents | Fewer unexpected losses during migration | Promises you can verify on your own files | | A path for automation and agents | Scenarios run without manual clicking | Preview, approval, audit, and rollback | ### The platform in brief [Section titled “The platform in brief”](#the-platform-in-brief) SumOffice gives your product its own embedded office engine: Word-grade documents and Excel-grade spreadsheets under your brand, in your storage, inside your security perimeter and your processes. The delivery includes the document and spreadsheet cores in Rust, an interface under your brand, a developer kit — working for documents, being finalized for spreadsheets — automation, and measurable compatibility through capability profiles and acceptance checks. ## What already works [Section titled “What already works”](#what-already-works) Plans are easier to read next to what already works today: [what SumDoc can do with a document](/sumdoc/capabilities/), [SumSheet’s capability map](/sumsheet/atlas/), and [the boundaries we state outright](/platform/risks/). # Security, privacy, and operations > Trust boundaries, secrets, storage, roles, logs, the supply chain, and lifecycle: what SumOffice provides, and what stays on your side. In an embeddable product, security is not a section at the end of the contract but part of the contract itself: the boundaries run right along the calls. For a security team this means it is known in advance where the trust boundaries are, what goes into the logs, which credentials never leave, how the runtime is updated, and how resources are released. The main rule: the core and the processor never call out. Documents stay inside your perimeter, and document content never goes into the logs. | Area | What SumOffice is responsible for | What stays on your side | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Network boundary | For documents, the editor service listens only on a local address: it cannot be reached from outside, even from your own network. For spreadsheets in the browser there is no separate service at all — the core computes in the page’s memory, and the workbook never leaves. Data providers do not go to the network without explicit permission in either case. | Set the allowed source addresses, root directories, and network rules. | | Secrets | The SumDoc editor service is protected by a pass, new on every start and valid while the service runs; secrets are cut out of the output, and credentials are passed as opaque identifiers. | Do not log passes, addresses, or credentials; choose where the performance metrics go. If you set your own pass, its strength and rotation on every start are your responsibility: the core only checks that the string is not empty. | | Storage | The save contract, transfer as bytes or a stream, address-based access only with a declared capability, replacing the file in one atomic action. | Paths, access rights, backups, retention periods, leak control. | | Read-only mode and roles | The restriction is checked when a command runs, not just by graying out buttons in the interface. | The roles themselves and permission decisions. | | Logs | Counters, durations, codes, and checksums — without the document’s content. | Agree on what gets redacted, what goes into the audit trail, and how long it’s kept. | | Supply chain | Signatures, component inventories, checksums, and update compatibility rules. Not everything is signed yet, and it differs by system — exactly what is verified today is summarized under [risks](/platform/risks/). | The rollout and rollback process, approvals, the support channel. | | Lifecycle | Closing twice is safe; acceptance requires that no resource stays held after shutdown. | Monitoring the process, timeout rules, deciding what happens to an unsaved document. | | Ready-made apps | The only outbound channel is the support assistant in the ready-made SumDoc and SumSheet apps. It sends to the support service only messages, problem reports, and automatic error reports: on desktop systems — a snapshot of the document window, a recording of the last minute of interface actions, and the app logs; on mobile — only the tail of the log. The same error is sent once, no more than five automatic reports per hour; there is no off switch. The support service is hosted by a partner ([privacy policy](https://sumoffice.com/app-privacy)). | Decide whether such a channel is allowed inside your perimeter; if it is not, do not deploy the ready-made apps — embed the core instead. | ## What can be collected without content [Section titled “What can be collected without content”](#what-can-be-collected-without-content) * the runtime version, the contract version, the capability profile identifier; * the operation identifier, the command family, duration in milliseconds, the outcome class; * document size to within a range and the number of structural elements — without the text itself; * the reason the process ended, peak memory use, timeout and retry counters; * versions of the system, WebView, browser, and runtime, and the update channel. Don’t log Tokens, full addresses, document text, comments, author names, source markup, workbook bytes, credentials, and absolute paths — unless a redaction rule is defined for them. ## What’s left of a redacted value [Section titled “What’s left of a redacted value”](#whats-left-of-a-redacted-value) Cutting out does not drop the value silently: a separate, deliberately sparse projection is built for the log. Whoever decides where such a log goes needs to know what it contains. What remains of a value is its length in bytes, a `sha256` hash, and, for binary data, up to the **first sixteen bytes**. The bytes themselves, base64, and field contents are never carried over; for records with fields, only their count and a “cut out” mark remain. Credentials, addresses, and local paths are masked **before** the value gets into the projection. But sixteen bytes of binary data remain, and the hash of a short value can be brute-forced — for a log that goes outside, this is worth considering separately. ## For developers [Section titled “For developers”](#for-developers) For documents everything is collected on one page; for spreadsheets it is split by topic. * The SumDoc service pass: 256 bits from the system’s source of randomness, new on every start; your own pass — [about `--token`](/reference/sumdoc/transport/). The minimal security model, the local address, and forbidden workarounds — [Responsibility and security](/sumdoc/responsibility/). * SumSheet, where the data stays: in the browser the workbook lives in the tab’s memory — [the core in the browser](/sumsheet/wasm/); on the server, client isolation, quotas, and the log remain yours — [the processor on the server](/sumsheet/server/). * SumSheet, boundaries for outside input: allowed directories and file types, a ban on passing a destination address from an external client — [integration into an application](/sumsheet/integration/). * SumSheet, what never leaves: credentials and the source text of Power Query queries and macros don’t go into events — [runtimes](/sumsheet/environments/); source privacy levels — [trust and privacy](/reference/sumsheet/pq-trust/). * What comes back in a refusal, and why a refusal is safer than silent corruption — [How the session API works](/sumsheet/session/). # What you get: in short > What you bring, what the platform does, and what comes out — the product formula in three parts. SumOffice gives your product its own document and spreadsheet editor: under your name, inside your system, with your access rights and your storage. You bring the product and the perimeter, we bring the document and spreadsheet engines. Below is what comes out. What is delivered is not a source archive and not someone else’s office suite with someone else’s interface, but an office processor inside your product—with a contract and commitments. | What you bring | What you get | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Brand, name, domain, the interface shell, help, and training | The editor looks like part of your product, not an external service: your colors, your language, your set of commands. | | Sign-in through your system, users, roles, licenses, audit | Documents stay inside your perimeter. Roles and rights are checked by your system, and every action leaves a trace in the audit log. | | Storage: files, document management and accounting systems | Files are saved where you say, with no hidden cloud on the vendor’s side. Document management systems connect over WOPI, the standard file exchange protocol; verified on Nextcloud, while SharePoint and ownCloud have not been verified. If the file was changed from outside, the editor refuses to save and names the reason. | | Your own real documents, a dozen key scenarios, critical features | Fidelity with Word and Excel is proven on your files rather than promised in general: a capability profile, an acceptance document set, and speed thresholds. | | The list of platforms: browser, Windows, macOS, Linux, phones, your own perimeter | One product gets desktop, browser, server, and mobile variants. The document and spreadsheet apps are published in the App Store and Google Play, the desktop ones in the Mac App Store. For your own mobile app there is a viewer kit for Android and iOS—under the same version number as the store build: [phone and tablet](/start/mobile/). | | Automation tasks: VBA, Power Query, agents, pipelines | Automation becomes controlled and verifiable: first show what will change, then confirm and apply. Anything unsupported is rejected with a reason rather than corrupting the file—[VBA, Power Query, and agents](/platform/automation/). | | Working together on one document | Several people edit one DOCX or XLSX at the same time inside your perimeter. Proven for text and cells (measured with five participants and 119 scenarios); objects and formatting under concurrent input are still being measured. How it works on the server—[the editor in the browser](/sumdoc/webhost/). | * For you, this isn’t buying an editor — it’s an office processor as a component of your own industry platform. * For your user, this isn’t a separate account and someone else’s window — it’s a familiar document or spreadsheet inside their current process. * For security and operations, this isn’t a black box: the declared capabilities, error codes, collected metrics, lifecycle, update rules, and acceptance criteria are all fixed in advance. Today the platform has two engines—documents and spreadsheets. The third, for presentations, is in development: a public beta is planned for December 2026, it cannot be downloaded yet, and PPTX compatibility, platforms, and speed are not promised. Platform terms — capability profile, explicit refusal, preservation of the unsupported, white-label delivery — are explained in the [glossary](/start/glossary/). ## Next [Section titled “Next”](#next) * What exactly is delivered—[What is delivered](/platform/delivery/). * What it looks like under your brand—[White-label setup](/platform/white-label/). * How to verify on your own files—[Pilot and acceptance](/platform/pilot/). # Customizing for your brand > What you can change, and what stays in the core: brand, styling, navigation, commands, storage, users, events, and localization. White-label delivery isn’t a cosmetic wrapper over someone else’s product; it’s a division of responsibility. The outward-facing product and the user journey belong to you. The meaning of the document and the spreadsheet — how the file is parsed, calculated, and written — stays in the core and doesn’t fork. For the business this means one thing: the editor carries your name and lives in your process, but you don’t end up with your own version of the engine that you’d have to maintain, update, and audit for security. | Area | What you can change | What you can’t do | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Brand | The product name, logo, tab icon, links to legal documents, shell colors. | Change document content bypassing the core. | | Styling | Documents have five theme variables and a choice of light or dark theme. Spreadsheets don’t have such a list yet: the public embedding kit is still being finalized — [what’s in it today](/sumsheet/embedding-api/). | Changing the canvas geometry with styles: page layout is calculated in the core, and the screen will diverge from the file. | | Navigation | Your application’s routes, where open and save live, your own side panel, tooltips, and onboarding. | Relying on the internal structure of the interface: it changes without notice. | | Commands | Showing commands based on declared capabilities, enabling and disabling them by your own rules, adding your own panels. For spreadsheets, the list of commands ships in the delivery as a registry: 472 commands on 28 interface surfaces, each recording where it lives and which checks cover it. You can plan from the registry; you can’t plan from screenshots. | Show commands that aren’t in the declared profile: the user will click and get a refusal. | | Storage | Your own open and save adapters — or the ready-made WOPI client, if your document management system speaks it; version history, autosave rules, auditing. | Bypass the save contract or write to the document file directly. | | Users | The account from your sign-in system, workspace context, roles. | Pass credentials into document data or into logs. | | Events | Analytics and audit through the public set of events. | Treating internal interface events as a public contract. | | Localization | Language packs, your own terminology in labels. | Split the meaning of the same command across different brands. | ## How deep you can go [Section titled “How deep you can go”](#how-deep-you-can-go) * **The ready-made shell.** The ribbon, grid, dialogs, and File menu entirely from us, inside your window. For documents, the server option provides such a shell: the whole editor opens in an embed on your site. The standalone SumDoc surface for your own window isn’t it: today it’s a limited set that proves the embedding boundary, not a ribbon with dialogs ([what’s in it](/sumdoc/embedding/)). * **The mixed option.** The document or spreadsheet canvas from us, while the interface frame, panels, and industry-specific commands are yours. The only one of the four that starts with a conversation rather than a download: for documents, the set of your own panels and menu items [is fixed in the pilot](/sumdoc/status/); for spreadsheets, the public embedding kit is still being finalized. * **Core only.** Your interface calls the public operations and renders what it gets back itself. * **Automation only.** A headless process: batch processing, agents, checks, and document creation. ## For developers [Section titled “For developers”](#for-developers) * Theme variables of the SumDoc surface: `--fastdoc-accent`, `--fastdoc-background`, `--fastdoc-foreground`, `--fastdoc-muted`, `--fastdoc-paper`. * The SumSheet interface is driven by a registry of 472 commands — each records which of the 28 surfaces it lives on — besides the File menu and the Data, Insert, View, Layout, and Review ribbons, these are the canvas, the formula bar, dialogs, and the contextual ribbons for tables, pivots, and charts — and at which stage it becomes available; five commands are marked as not exposed outward — your own shell has nothing to show them with. * Allowed and forbidden customization points of SumDoc — [Responsibility and security](/sumdoc/responsibility/); the boundary between the surface and the SumSheet core — [the embedding kit](/sumsheet/embedding-api/). # AI tools and MCP > Two SumOffice MCP servers — for the documentation and for your file — llms.txt and the "Ask the documentation" widget for Claude, Cursor, VS Code and ChatGPT. The main SumOffice MCP server works with your file: the agent opens a document or workbook in a private editor cabin, reads it the way the engine does, proposes an edit and applies it after you say yes. It is described in [section 1](#1-product-mcp-server). The second server is about the documentation. The reference is large — 41 session commands, 321 SumDoc shell methods, 487 request and response types and 208 SumSheet contract operations — and neither a person nor an assistant needs to keep it in their head. That is why the site offers its content in three machine-readable forms: [section 2](#2-documentation-mcp-server), [llms.txt](#3-llmstxt) and the widget on every page. ## 1. Product MCP server [Section titled “1. Product MCP server”](#1-product-mcp-server) This server works not with the documentation but with your document or workbook. The agent opens the file in a private editor cabin on the viewing server, reads it the way the engine does — formulas, macros, Power Query, paragraphs, comments — proposes an edit, applies it after you say yes and hands back a copy that Word and Excel open without a repair dialog. The original is never changed. ### Connect in one minute [Section titled “Connect in one minute”](#connect-in-one-minute) Address: `https://view.sumoffice.com/mcp`, streamable HTTP. Any MCP client works; no account, no key. Each session gets its own cabin; files and copies are deleted after 24 hours. claude\_desktop\_config.json ```json { "mcpServers": { "office": { "command": "npx", "args": ["-y", "mcp-remote", "https://view.sumoffice.com/mcp"] } } } ``` Claude Code: ```bash claude mcp add --transport http office https://view.sumoffice.com/mcp ``` Cursor and other clients connect the same URL as a remote server. **Local files.** The same server is available as the Docker image `hissih/sumoffice-mcp` (linux/amd64 and arm64). It runs on your side, accepts a path inside the mounted folder, and opens the file itself in a sandbox on the server, just like the remote variant: ```json { "mcpServers": { "office-agent": { "command": "docker", "args": ["run", "-i", "--rm", "-v", "/path/to/files:/work", "hissih/sumoffice-mcp"] } } } ``` Then — `document_open_file` with `path: "/work/report.xlsm"`. | Step | Tools | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Open | `document_open_file` — your file by `url`, as `base64` with a `name` or, in the Docker image, by `path`: .docx, .doc, .odt, .xlsx, .xlsm, .xlsb, .xls, .ods, up to 50 MB. `document_open` — a demo file by name, to try it out. | | Read a workbook | `sheet_describe` (sheets, used ranges, revision), `sheet_read` (values and formulas of a range), `sheet_find`; `macro_list`, `macro_read_source`, `macro_plan` — the VBA project: entry points, routes, obstacles, nothing is run; `query_list`, `query_explain` — Power Query steps and where they load to; `workbook_inspect` — the whole workbook model in one call. | | Read a document | `document_describe`, `document_read` (paragraphs in a window), `document_find`, `document_comments` (comments and tracked changes). | | Change | `sheet_propose_edits` → `sheet_apply`: up to 20 cells, the engine first shows what will change, whether errors will appear and whether input numbers get overwritten. `document_propose_replacement` → `document_apply`: new text for one paragraph, with “before — after” and checks. Nothing changes before the `apply` call; a proposal against an outdated revision is rejected, not applied silently. | | Collect | `document_save_copy` — the changed file as a link valid for 24 hours; a workbook with macros comes back as .xlsm with the VBA project untouched. `document_export_pdf` — the document as laid out by the engine, as a PDF with the page count. | The same cycle — look, propose, wait for permission, apply — is available in the agent panel inside the editor; how it works and why the refusal comes before the change — [VBA, Power Query and agents](/platform/automation/). ## 2. Documentation MCP server [Section titled “2. Documentation MCP server”](#2-documentation-mcp-server) The documentation site runs its own [MCP](https://modelcontextprotocol.io) server at `/mcp` — not to be confused with the product server above: this one answers questions about the documentation and does not work with your file. Tools: | Tool | Arguments | What it returns | | ------------- | ------------------------------- | ------------------------------------------------------------------------------------- | | `search_docs` | `query` | Up to five most relevant pages with URL, description and an excerpt around the match. | | `get_doc` | `path` — page identifier or URL | The full text of the page in markdown. | | `list_docs` | — | All pages with titles and descriptions. | The tool catalog in machine-readable form: `/mcp-schema.json`. ### Claude Code [Section titled “Claude Code”](#claude-code) ```bash claude mcp add --transport http fastoffice-docs https://docs.sumoffice.com/mcp ``` ### Cursor [Section titled “Cursor”](#cursor) .cursor/mcp.json ```json { "mcpServers": { "fastoffice-docs": { "url": "https://docs.sumoffice.com/mcp" } } } ``` ### VS Code [Section titled “VS Code”](#vs-code) .vscode/mcp.json ```json { "servers": { "fastoffice-docs": { "type": "http", "url": "https://docs.sumoffice.com/mcp" } } } ``` ### Clients that only speak stdio [Section titled “Clients that only speak stdio”](#clients-that-only-speak-stdio) ```json { "mcpServers": { "fastoffice-docs": { "command": "npx", "args": ["mcp-remote", "https://docs.sumoffice.com/mcp"] } } } ``` ## 3. llms.txt [Section titled “3. llms.txt”](#3-llmstxt) For tools that work with text dumps, the site publishes six files. All of them are generated at build time from the same content as the site and open by direct link. | File | What is inside | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [`/llms.txt`](/llms.txt) | The table of contents: links to the other files with descriptions. The entry point. | | [`/llms-full.txt`](/llms-full.txt) | The whole documentation in one file, about 2.9 MB. | | [`/llms-small.txt`](/llms-small.txt) | The same material without the reference field tables, about 2.2 MB. That is still a lot: if the model has a small context, take a topical set below instead. | | [`/_llms-txt/a4-reference.txt`](/_llms-txt/a4-reference.txt) | The SumDoc reference only: Session Protocol, `window.fastdocShell`, DTOs, events. | | [`/_llms-txt/f1-reference.txt`](/_llms-txt/f1-reference.txt) | The SumSheet reference only: Compute Contract, 208 operations. | | [`/_llms-txt/platform-overview.txt`](/_llms-txt/platform-overview.txt) | The product part: white-label delivery, security, the pilot. | ## 4. The chat assistant on the site [Section titled “4. The chat assistant on the site”](#4-the-chat-assistant-on-the-site) The button in the bottom-right corner opens a chat about the documentation. It is a full conversation: you can refine as you go without repeating the context. The answer streams in, and the conversation is kept in the browser until your next visit. Under every answer is a list of sources. Check them: the answer is worded by a model, and it may be inaccurate. Answers are built from the documentation only The assistant answers solely on the basis of the pages of this site. If the documentation does not have what you need, it says so instead of inventing a command or field name. If answers are switched off — no model key is set or the quota has run out — the chat shows the sections it found, with links. ## 5. The “Open in…” buttons on pages [Section titled “5. The “Open in…” buttons on pages”](#5-the-open-in-buttons-on-pages) The header of every documentation page has an actions menu: copy the page as markdown or open its content in ChatGPT or Claude. This lets you ask about one specific page without connecting MCP. ## What to choose [Section titled “What to choose”](#what-to-choose) | Task | Tool | | ---------------------------------------------------- | ------------------------------------------ | | Writing integration code in an IDE with an assistant | The MCP server for the documentation | | The agent has to read or fix my file | The MCP server for the product | | A one-off question about the open page | The “Open in…” button | | Quickly find where something is described | The “Ask” widget or site search | | Loading the documentation into my own pipeline | `/llms-full.txt` or `/mcp/docs-index.json` | # Early access request > The request form for the SumDoc and SumSheet beta program: early builds, a direct line to the team and a say in priorities. You can download the current build right now without asking anyone: SumDoc and SumSheet for macOS (Apple Silicon and Intel), Windows, and Linux are on [dl.layers.md](https://dl.layers.md/sumoffice/sumdoc/release/latest/) together with checksums — [how to verify SumDoc](/sumdoc/install/) and [SumSheet](/sumsheet/install/). Early access isn’t for that. It is about something else: you get builds before the public release and a direct channel to the team, bypassing the general support queue — so your feedback makes it into the release rather than onto a list for later. What is expected in return: open your real documents in a new build from time to time and report discrepancies. Participation is free; no contract is required. [Early access request for SumDoc and SumSheet](https://app.sumoffice.com/p/fastdocs/forms/c17aa083-1d75-48e8-bb7c-a372ff0651da) If the form did not open or is awkward to fill in inside the frame — [open it as a separate page ↗](https://app.sumoffice.com/p/fastdocs/forms/c17aa083-1d75-48e8-bb7c-a372ff0651da). You can also simply write to [](mailto:hello@sumoffice.com?subject=%D0%B1%D0%B5%D1%82%D0%B0) with “beta” in the subject. ## What happens next [Section titled “What happens next”](#what-happens-next) We answer a request by email within one business day: we send the build, a short description of what already works in it and what is still rough. If you need verification on your own documents as part of your workflow, rather than a trial of the build — that is a pilot: it is structured differently, goes in stages, and fixes the terms in advance. What exactly is verified there — [Pilot and acceptance](/platform/pilot/). Other ways to get in touch are on the [Contact us](/start/contact/) page. # Contact us > How to request a pilot, join the beta and ask a question about embedding SumDoc or SumSheet. Write to **** — the shared address for every request below. The team that builds SumDoc and SumSheet answers — within one business day. The supplier of SumDoc and SumSheet is \[\[var:legal.entity]]. Company details and trademarks are on the [legal information page](https://sumoffice.com/legal.html); personal data processing is in the [privacy policy](https://sumoffice.com/app-privacy). Files you send for a check or a pilot are used only to run them through the engine, are not passed to third parties, and are deleted on your request to the same address. ## Request a pilot [Section titled “Request a pilot”](#request-a-pilot) A pilot is not a presentation but a check on your documents: you open your file inside your application, edit it, save it and reopen it. What exactly is checked and how long it takes is described on the [Pilot and acceptance](/platform/pilot/) page. To get straight to business, it helps to state up front: * which product you need — SumDoc (DOCX documents), SumSheet (XLSX spreadsheets) or both; * what your application is built on — desktop, web or server-side processing; * which operating systems must be supported; * what the user must be able to do inside the document; * whether there are perimeter restrictions: an air-gapped network, data storage requirements; * volume — how many documents and how many installations; * timeline — when you want to start the pilot. Attach a representative document without confidential data — this is the fastest way to start. We run it through the engine and reply with what opens, what saves without loss, and what will need further work — before any commitments. The cost depends on which application embeds the engine and how it is delivered. Describe that — and within one business day you will get a written proposal; no call is needed for this. ## Beta program [Section titled “Beta program”](#beta-program) The SumDoc and SumSheet builds are openly available — [installing SumDoc](/sumdoc/install/) and [installing SumSheet](/sumsheet/install/) — no request is needed for that. If you are ready to try builds before the general release and send your remarks, leave a request — [the form on the next page](/start/beta/), three fields. An email with **beta** in the subject works too — [an email with the subject filled in](mailto:hello@sumoffice.com?subject=%D0%B1%D0%B5%D1%82%D0%B0). Participation is free. In return we ask for feedback: what did not open, what opened incorrectly, what was missing. What participation gives: * early access to SumDoc and SumSheet builds before the public release; * a say in priorities — feedback from beta participants is taken up before anything else; * a direct channel to the team without the general support queue. What is expected from a participant: open your real documents in a new build from time to time and report discrepancies. No formal obligations or contract are required. ## Technical question [Section titled “Technical question”](#technical-question) If you are already reading the reference and something specific does not add up — a command, an operation, a field, behavior on error — write to the same address and include: * which product, build version and operating system; * what you called and what you expected to get; * what you got instead, including the full error text. For spreadsheets that is the operation name and the `code` from the response; documents have no code — include the `error` line and the command name, and if an edit is involved, also `result.mutation.result_kind`: it arrives even when the envelope is successful; * one full request line and one full response line; * the smallest anonymized file that shows the problem; * whether it reproduces in a new process. Before writing, it is worth looking at the troubleshooting pages — [for SumDoc](/sumdoc/diagnostics/) and [for SumSheet](/sumsheet/diagnostics/): some cases are already covered there, along with what exactly to check. ## An error in the documentation [Section titled “An error in the documentation”](#an-error-in-the-documentation) Found an inaccuracy, a cut-off sentence or a link to nowhere on this site? Write to the same address with **documentation** in the subject — [email with a ready subject](mailto:hello@sumoffice.com?subject=documentation) — and give the page address. It helps more than it seems. # Embed into a desktop application > First steps for a program on a computer — an accounting system, an ERP, an industry platform: what to put alongside it, what to start, and what to send so that a document opens, changes, and saves. 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 [Section titled “How it works, in a nutshell”](#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 [Section titled “Three steps”](#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](/sumdoc/install/). 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. ```bash "$CLI" serve ``` The reply is a readiness line; from it your program knows it can start working: ```json {"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: ```json {"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: ```json {"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 [Section titled “What to know right away”](#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 [Section titled “Show a document without the editor”](#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: ```bash "$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 [Section titled “If you need to show the editor itself”](#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](/sumdoc/embedding/) 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](/sumdoc/surface/) ## The same for spreadsheets [Section titled “The same for spreadsheets”](#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](/sumsheet/native/). 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](/sumsheet/server/). ## Further on, when the simple path is not enough [Section titled “Further on, when the simple path is not enough”](#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](/sumdoc/capabilities/) | | Export the finished document to PDF, including with embedded fonts | [Printing and publishing](/sumdoc/capabilities/#printing-and-output) | | Check how a third-party file is protected and which macros it has, without running them | [File security](/sumdoc/capabilities/#file-security) | | Recalculate a workbook, build a pivot table, refresh a data query | [Capability map next to Excel](/sumsheet/atlas/) | | Understand what comes in a reply and how to read a refusal | [Request and response objects](/sumdoc/envelope/) | | The exact names of all calls, with fields | [SumDoc reference](/reference/sumdoc/overview/), [SumSheet reference](/reference/sumsheet/overview/) | [Embed into a web application](/start/web/)If your product lives in the browser: the editor opens right on your page. [Embed into a mobile application](/start/mobile/)What is possible on a phone and a tablet today and what is not yet — honestly and without promises. # Glossary > Platform terms in plain words: core, session contract, operations contract, capability profile, explicit refusal, preservation of the unsupported, white-label delivery. Terms that appear throughout the documentation. | Term | Meaning | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SumDoc core, the Rust core | The part of SumDoc that owns the document: it reads the DOCX file, computes the page layout and writes changes back to the file. | | SumSheet core, the Rust core | The part of SumSheet that owns the workbook: formulas, cell storage, edit history and writing the file; there is no second owner—the screen only shows and asks. | | Editor surface, Web Surface | The editor page shown in a browser or in a web view inside an application; for SumDoc this is a trial surface—it shows and edits the first paragraph and sends the application five events, while the full editor comes as the [web host](/sumdoc/webhost/) or the desktop app. | | Surface Host, the surface service | A small program on the same machine where the document is open: it serves the surface page and holds one session, and cannot be reached from outside. | | `fastdoc`, `fastsheet` in names | The internal names of SumDoc and SumSheet before they were renamed: they remain in code, events and settings so as not to break existing embeddings. | | Your application, the host application | The application the editor is embedded into; it owns the brand, user sign-in, storage and workflows. | | Application adapter | Your code between the application and the editor: it starts the core, passes commands and parses responses, and never touches the file itself. | | Evaluation Kit | A ready-made set for a first trial—examples, sample documents and the expected result of each step—so that your engineer opens their own document in 30–60 minutes. | | Mashup, query set | A set of Power Query queries inside a workbook; a “foreign” one was built in Excel or another program: SumSheet reads it, refreshes it and writes it back without losing what it doesn’t understand. | | DTO, data transfer object | A description of the shape of a request or response: which fields exist, what type they are and which are required. | | OEM, white-label embedding | A delivery where the user sees your interface and your name, not ours; an “OEM profile” is the set of events and settings for such a delivery. | | Smoke run | A short automated check that the program starts and opens a document; such routes are not needed in embedding and are marked separately in the reference. | | LTS, long-term support | A version for which fixes and security updates are released for an agreed period, not just until the next release. | | Single sign-on, SSO | The user signs in to the editor with the same account as your product: your system verifies them, and the editor receives only the name, role and permissions. | | Session contract, Rust Session Protocol | The list of what your application can say to the SumDoc editor and what it will hear back; it has a version and never changes silently—[all commands](/reference/sumdoc/session-protocol/). | | JSONL session | The simplest way to talk to the core: your program sends a line with a task and receives a line with a response, one complete JSON message per line. | | Standard input and output, stdin and stdout | The two streams through which a running program receives tasks and responds; a JSONL session works over them and needs no network port of its own. | | Token | A random string the core creates at startup, without which its port cannot be connected to; on the next start it will be different unless you set it yourself—[for developers](/reference/sumdoc/transport/). | | Local address, 127.0.0.1 | The address of the machine itself: a port on it cannot be reached from outside, even from your own network. | | Policy enforcement point | A known-in-advance moment when the editor asks your application whether it may continue—before a command, before saving, before sending data out; the rules remain yours. | | Agent | A program that works with the document in place of a person, by the same path as the interface, so its actions are visible, verifiable and undoable; it cannot edit the file behind the editor’s back. | | Operations contract, Compute Contract | The only path to an SumSheet workbook for the interface, automation and adapters; all operations are in the [reference](/reference/sumsheet/overview/), 206 of them are accepted by the core of the latest release, and acceptance is measured against it. | | Capability profile | A named list of what is included in your delivery: features, platforms, formats, operations and limits; the promise is defined by it, not by general words. | | Capability matrix | A table where each capability is verified by format, environment, action and markup preservation: the profile says what is in the delivery, the matrix says what of it has been verified and on what. | | Explicit refusal | A response with a code and a reason that arrives **before** the document changes: an operation won’t fail silently and won’t half-corrupt the file—[how to read a response](/sumdoc/envelope/). | | Preservation of the unsupported | Parts of the file the editor doesn’t understand end up in the saved file unchanged or are honestly flagged—this is what sets an editor apart from a converter, which loses everything unfamiliar. | | White-label delivery | The editor ships under your name and in your interface; what is customized is the shell, not the meaning of the document. | | Within the described boundaries | Exactly what has been done and verified is listed; beyond the boundary a capability refuses predictably, with a clear reason, rather than breaking. | | Bounded | About SumSheet operations with `bounded` in their name: they work only with the part of the workbook you requested; not to be confused with the row above—that one is about a capability’s readiness, this one is about a piece of the workbook. | | Workbook session, workbook subset, subset, `subsetId` | A workbook open in SumSheet and its number, passed to all subsequent operations on it: the session lives only inside the running process, and a macro in the workbook itself may prevent closing it—[how a session works](/sumsheet/session/), [what happens on close](/reference/sumsheet/session/#close_workbook_subset). | | Viewport, visible area | A rectangular area of the sheet the core sends to the screen; moving it is not an edit and doesn’t enter the history. Both names appear on the pages and mean the same thing—[for developers](/reference/sumsheet/session/#synchronize_workbook_viewport). | | Revision, `revision`, `expectedRevision` | The workbook state number that grows with every edit: if you pass the last number you saw in a request and the workbook has changed since, the request is rejected **before** the change—protection against editing from two places at once. In SumSheet the field is optional: without it the edit is applied unconditionally—[How the API session works](/sumsheet/session/). | | Power Query, M expression | A mechanism for fetching and transforming data from external sources step by step, compatible with the mechanism of the same name in Microsoft Excel. | | Writeback | Transferring changes from the document model back into the DOCX or XLSX file; parts the edit didn’t touch are carried over unchanged, and the core does this, not the interface. | | Projection | A slice of state the core sends to the interface: exactly what the current screen needs, not the whole document or workbook. | | Sparse workbook state | Only filled cells and explicitly set formats are kept in memory, so a sheet with a million rows takes no memory for empty rows; on open, the active sheet is loaded first. | | Headless, working without an interface | A mode where the core works without a screen: it receives commands and returns data or a finished file—this is how it’s used on a server and in batch processing. | | Dirty, unsaved changes | The state where the document has edits that are not yet in the saved file; the application usually shows this and asks for confirmation before closing the window. | | Cold reopen | Opening a saved file again, in a new process, to verify that everything the editor showed made it into the file: the edit, the history, the formatting and the unsupported parts. | | Acceptance | A pre-agreed set of documents and actions on which the integration is verified: not “we support DOCX” but “on these files these operations give this result”. | | Privacy level | The privacy level of a data source in Power Query: it prevents mixing a private source with an external one in the same query, so that data doesn’t leak. | # How to read this documentation > Which sections the site consists of, where to start depending on your role, and what all the numbers and claims are based on. The documentation is split into four levels — from the big picture for an executive to the reference for a developer. You don’t need to read it all in order: pick your section and your route. ## Structure [Section titled “Structure”](#structure) | Section | For whom | Contents | | --------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Platform](/platform/story/) | Executive, product, presales, procurement, security team | Why this instead of someone else’s office suite, what you get, what is delivered, customizing under your brand, parity with Word and Excel, security, the pilot, and commercial terms. | | [SumDoc](/sumdoc/overview/) | Architects and integrators of the document part | How the document editor works, how to install it, run it, and embed it in your application. | | [SumSheet](/sumsheet/overview/) | Architects and integrators of the spreadsheet part | How the spreadsheet editor works, where it runs, how to install and embed it. | | [SumDoc reference](/reference/sumdoc/overview/) | Developers | All session commands (41), editor window methods (321), events and data types (487) — with fields. | | [SumSheet reference](/reference/sumsheet/overview/) | Developers | All contract operations (208) by area, with request and response fields. | ## Reading paths [Section titled “Reading paths”](#reading-paths) **See it with your own eyes without installing anything.** [Document editor](/sumdoc/demo/) → [spreadsheet with a cost estimate](/sumsheet/demo/) → [twenty-three embedding examples](/sumsheet/examples/) and [a project for documents](/sumdoc/examples/). Both editors open right on the page and work for real: you can edit a paragraph in the document and change numbers in the estimate. The code of each example is shown right there. **An evaluation in one evening.** [What SumOffice is](/start/intro/) → [What you get](/platform/story/) → [Feature parity](/platform/parity/) → [Pilot and acceptance](/platform/pilot/). **A technical prototype with SumDoc.** [Installing SumDoc](/sumdoc/install/) → [Quick start](/sumdoc/quickstart/) → [Request and response objects](/sumdoc/envelope/) → [Session commands](/reference/sumdoc/session-protocol/). **A technical prototype with SumSheet.** [Installing SumSheet](/sumsheet/install/) → [Quick start: the first project](/sumsheet/quickstart/) → [How the API session works](/sumsheet/session/) → [Compute Contract reference](/reference/sumsheet/overview/). **Designing an SumDoc integration.** [Architecture](/sumdoc/architecture/) → [Lifecycle](/sumdoc/lifecycle/) → [Host API](/sumdoc/host-api/) → [the interaction contract](/sumdoc/interaction/) → [What to fix before integrating](/sumdoc/status/#what-to-lock-in-before-integration-begins). The two pages in the middle describe an interface that is still being proposed rather than working: they are what the shape of the future contract is agreed on. What is available today — [Readiness and boundaries](/sumdoc/status/). **Designing an SumSheet integration.** [Architecture: four layers](/sumsheet/architecture/) → [What happens from opening to saving](/sumsheet/lifecycle/) → [Runtimes](/sumsheet/environments/) → [Integrating into an application](/sumsheet/integration/) → [Readiness checklist](/sumsheet/checklist/). **A security review.** [Platform security](/platform/security/) → [SumDoc responsibility and security](/sumdoc/responsibility/) → [Risks and boundaries](/platform/risks/). ## What the documentation is based on [Section titled “What the documentation is based on”](#what-the-documentation-is-based-on) The documentation is assembled from the specifications of both products and checked against their source code. Every number, command name, refusal code, and capability boundary is verified against the code before every change. If the documentation diverges from the product, the edit goes no further. When the site is built, the checks run again — on a machine where there is no source code. There it is verified that the pages match their generator, that all links lead to existing pages, and that no internal material has made it into the public text. Command names are checked against a list taken from the delivery itself, and the number of operations against a list taken from the release’s core. If a check fails, there is no deployment. This does not apply to the comparison with Excel: it relies on official Microsoft documentation, and the sources are named right on the page [Capability map next to Excel](/sumsheet/atlas/). # What SumOffice is > An office platform you embed in your product: SumDoc for Word documents and SumSheet for Excel spreadsheets — under your name and inside your perimeter. **SumOffice** is an office platform you embed in your product. Your users open and edit Word documents and Excel spreadsheets inside your application, under your name. Files never leave for someone else’s office suite or someone else’s cloud. The platform consists of two engines and a shared embedding model: | Engine | Files | What it gives | Documentation | | ------------ | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | **SumDoc** | DOCX | A ready-made document editor: opens a Word file, shows pages, lets you edit, saves and reopens. In the browser, the full editor opens on your domain. There is also a lightweight surface for trying out embedding — it can do less. | [SumDoc section](/sumdoc/overview/) | | **SumSheet** | XLSX | A ready-made spreadsheet editor: grid, formulas, edit history, import and saving. Large workbooks open because only what’s needed is kept in memory. It can calculate both on your server and right in the user’s browser — with no server at all. | [SumSheet section](/sumsheet/overview/) | A third editor — for presentations — is in development; the public beta is planned for December 2026. It can’t be downloaded yet, and PPTX compatibility, platforms, and speed are not promised. What exactly is promised SumOffice doesn’t copy Microsoft Office in full and doesn’t promise to be better than it. The promise is different: **on your documents and your operations, the editor does the same as Word and Excel**, and this is verified at acceptance. On top of that — what Office doesn’t have: the editor lives inside your product, under your control, with saving, automation, and verifiable acceptance. More — [Feature parity](/platform/parity/). ## Three things worth understanding right away [Section titled “Three things worth understanding right away”](#three-things-worth-understanding-right-away) 1. **Who owns what.** You own the product, the brand, user sign-in, storage, and the business process. SumOffice is responsible for what happens to the document inside. The boundary between them is narrow and fixed by the contract — see [Customizing under your brand](/platform/white-label/). 2. **A document has one owner — the core.** The document model, formulas, history, and file writing live in the platform’s core. The screen only shows the document and passes to the core what the user wants; it doesn’t write the file itself. 3. **A refusal is better than silent corruption.** If an operation can’t be performed, the answer with the reason arrives **before** the file changes. There is no such thing as a half-corrupted file. For developers — [how to read an SumDoc response](/sumdoc/envelope/) and [how an SumSheet response is structured](/sumsheet/session/). ## Where to start [Section titled “Where to start”](#where-to-start) If you don’t know where to start, see [how to read this documentation](/start/how-to-read/): it has routes by role. | Role | First page | | -------------------------------------- | ------------------------------------------------------------------------------------------------- | | Executive, product, presales | [What you get](/platform/story/) | | Architect | [SumDoc architecture](/sumdoc/architecture/) and [SumSheet architecture](/sumsheet/architecture/) | | Integrator | [SumDoc quick start](/sumdoc/quickstart/) or [SumSheet quick start](/sumsheet/quickstart/) | | Security team | [Security and operations](/platform/security/) | | An AI assistant reading on your behalf | [AI tools and MCP](/start/ai/) | | An agent that edits your file | [Product MCP server](/start/ai/#1-product-mcp-server) | # Add the editor without a programmer > A document and spreadsheet editor on your site, in your desktop program and on your phone. Tell Claude what you need and it will do it. No programmer required. § 01 · the promise A Word and Excel editor inside your product — on the site, in the desktop program and on the phone. You don’t need to be a programmer and you don’t need to wait for anyone. Copy the task, hand it to Claude—and in half an hour look at a working editor with your own document.  This is not a mock-up: the same editor is open right on this site —[try it yourself](/sumdoc/demo/). 1. **Copy the task**it is ready, below 2. **Hand it to Claude**it reads our documentation itself 3. **See the editor**with your document § 02 · integration ## Choose what you are integrating into [Section titled “Choose what you are integrating into”](#choose-what-you-are-integrating-into) ### Into a website [Section titled “Into a website”](#into-a-website) Your product lives in the browser. The editor opens right on the page — the user goes nowhere, the file stays with you. Task for Claude — copy it whole ```text Connect to the MCP server https://docs.sumoffice.com/mcp and, following the page "Embed into a web application", set up the document editor on a test page for me. I am not a programmer: explain step by step in plain words and ask if you need anything from me. ``` [What happens step by step →](/start/web/) ### Into a desktop program [Section titled “Into a desktop program”](#into-a-desktop-program) An accounting system, an industry platform, an ERP add-on. The editor opens inside your program, and you know about every change. Task for Claude — copy it whole ```text Connect to the MCP server https://docs.sumoffice.com/mcp and, following the page "Embed into a desktop application", show me how to open, change and save a document from my program. I am not a programmer: make a small example that I can simply run and see the result. ``` [What happens step by step →](/start/desktop/) ### Into a mobile application [Section titled “Into a mobile application”](#into-a-mobile-application) Phone and tablet. For viewing there’s a ready-made kit for Android and iOS—the same one used in our store apps. For editing from a phone, your server computes the document and your app shows the screen. Task for Claude — copy it whole ```text Connect to the MCP server https://docs.sumoffice.com/mcp and, following the page "Embed into a mobile application", explain which parts of the mobile path work today and which do not yet, and build me a small test application so that I can see the editor on my phone. ``` [What happens step by step →](/start/mobile/) § 03 · verification ## What you will see [Section titled “What you will see”](#what-you-will-see) Not a screen recording and not a picture: both programs open right here, in the browser, with no installation. Only you see your edits. A contract in the SumDoc editor Headings, lists, a table with deadlines and an amount. Edit a paragraph and see what the editor looks like inside a third-party application. [Open the live editor →](/sumdoc/demo/) An estimate in the SumSheet spreadsheet Formulas, shares, two totals. Change a quantity or a price—the totals recalculate on their own. [Open the live spreadsheet →](/sumsheet/demo/) § 04 · capabilities ## What the editor can do [Section titled “What the editor can do”](#what-the-editor-can-do) Short and to the point — what documents are opened for in the first place. | What you need | Documents | Spreadsheets | | -------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | Open and save without loss | DOCX, as well as ODT, RTF, HTML, plain text, EPUB, FB2 | 13 formats: XLSX, XLSB, XLSM, ODS, CSV and others | | Format | headings, lists, headers and footers, watermarks, tables, pictures and shapes | width and height, merging, themes, conditional formatting | | Assemble a document | table of contents, list of figures, bibliography, fields and references | pivot tables, subtotals, filters | | Work together | comments, tracked changes, comparing and merging versions | sheet and range protection, review | | Compute | — | formulas, recalculation, dependency tracing, Power Query | | Publish | printing, PDF, including with embedded fonts | printing, page layout, export | | Inspect a third-party file | the macros it contains without running them, how it is protected, readiness for archival PDF/A | macros, protection, compatibility | The full maps — [what SumDoc can do with a document](/sumdoc/capabilities/) and [the map next to Excel](/sumsheet/atlas/). § 05 · the agent ## An agent within the document’s rules [Section titled “An agent within the document’s rules”](#an-agent-within-the-documents-rules) An AI assistant that “knows how to work with Excel” usually clicks around the interface or writes to the file behind the editor’s back. Then nobody knows what exactly changed, and it can’t be undone in one move. Here the agent takes the same path as a person: the same actions, the same edit history, the same save. 1. looked 2. made a plan 3. showed the exact changes 4. waited for permission 5. applied as a whole 6. verified A refusal arrives **before** the file changes, and what was applied is undone in one action—not cell by cell, but all at once. Details—[VBA, Power Query and agents](/platform/automation/). § 06 · origins ## Thank you, Microsoft [Section titled “Thank you, Microsoft”](#thank-you-microsoft) In 1985 Excel showed that complex calculations could become part of everyday work. Word and Excel taught whole industries to work with documents, and business still runs on these formats — including your contracts and estimates. We do not want to cross out that path. We want the work it made possible to continue where Office itself cannot be: inside someone else’s application, on a server, in an automated process. **Your system used to be embedded into Excel. Now the Excel class is embedded into your system.** § 07 · why it is fast ## Why the assistant gets it done in half an hour [Section titled “Why the assistant gets it done in half an hour”](#why-the-assistant-gets-it-done-in-half-an-hour) Documents have **41 commands**, spreadsheets have **208 operations**, of which **206** are accepted by the core of the latest release. Each of these numbers is taken from installed builds, not copied from plans, and is checked twice: on our side against the products’ source code, and when the site is published against lists taken from the delivery itself. If even one diverges, the site isn’t published. That’s why the assistant gets it done in half an hour: it reads not marketing but a description that matches the program. [Download SumDoc](/sumdoc/install/)Builds for macOS (Apple Silicon and Intel), Windows and Linux are openly available, with checksums alongside. [Download SumSheet](/sumsheet/install/)The same systems and the same checksum verification; the release directory also contains the web host image. [Why your company needs this](/platform/replace-office/)What changes when the office suite is inside your product rather than next to it. # Embed into a mobile application > What exists today for the phone and the tablet: ready-made apps in the stores, a viewing kit for embedding and a server path for editing — step by step and without promises that nothing can back up. The SumDoc and SumSheet mobile apps are released: for iPhone and iPad — [SumDoc](https://apps.apple.com/app/id6807049845) and [SumSheet](https://apps.apple.com/app/id6807049725) in the App Store, for Android — [SumDoc](https://play.google.com/store/apps/details?id=com.sumoffice.sumdoc) and [SumSheet](https://play.google.com/store/apps/details?id=com.sumoffice.sumsheet) in Google Play. They are built the same way as described below: the editor screen inside an ordinary application. For your own application you have three paths. To show a document — the ready-made viewing kit (view SDK) for Android and iOS: the same engine and the same page as in the store apps, under the same version number. To let people edit from a phone — your server computes the document and your application shows the screen; this path works today. To edit right in the application, without a server — a separate delivery, which is agreed with the team. ## What exists today [Section titled “What exists today”](#what-exists-today) | Path | Documents (SumDoc) | Spreadsheets (SumSheet) | | --------------------------------------------- | --------------------------------------------------- | --------------------------------------------------- | | Ready-made app | App Store and Google Play. | App Store and Google Play. | | Viewing, the core inside your application | View SDK: Android (arm64-v8a) and iOS 16 and newer. | View SDK: Android (arm64-v8a) and iOS 16 and newer. | | Editing, the core on the server, your screens | Works. | Works. | | Editing, the core inside your application | A separate delivery, by agreement. | A separate delivery, by agreement. | The viewing kit is connected in three actions: add it to the project, show it in a web view, pass the file. Archives, checksums, the instructions and speed measurements are on the [viewing kit page](https://sumoffice.com/developers.html#mobile). What each of the paths costs — [Phone and tablet](/sumsheet/mobile/) and [where SumDoc is deployed](/sumdoc/deployment/). ## Editing from a phone through your server [Section titled “Editing from a phone through your server”](#editing-from-a-phone-through-your-server) The idea is simple: the phone does not compute the document, it shows it. The heavy work is done by the same core, but on your server — where it has memory and where you control it. For the business this means: the file and the edit history never leave your server, and the mobile application stays yours. The steps below are for whoever will do the wiring. 1. **Put the core on your server.** The same executable as for the desktop path. How it runs as a service — [The processor on a server](/sumsheet/server/) for spreadsheets, [The editor in the browser](/sumdoc/webhost/) for documents. 2. **Set up three addresses on your side.** This is your ordinary API, nothing special: ```plaintext POST /workbooks → open a document, return a session id POST /workbooks/{id}/commands → perform an action POST /workbooks/{id}/save → collect the finished file ``` This is how the mobile application talks to the core. Outward you hand out your own session id and never show the core’s internal names to the client. 3. **Show the document on the phone screen.** Two ways, and both are yours: * **a web view inside the application** — then the editor shell draws the screen, and you do not need to build an interface; * **your own screens in Swift or Kotlin** — then you draw everything yourself and ask the core only for the content. 4. **Take a narrow scenario for the first pilot.** Not “all of Excel in your pocket” but one clear task: open a workbook → find and change the needed range → save. Such a pilot can be completed and shows the real cost of the work. ## What to expect from a phone and what not to [Section titled “What to expect from a phone and what not to”](#what-to-expect-from-a-phone-and-what-not-to) * **Less memory.** A large workbook has to be held in an even smaller portion than on a computer. * **The system may evict the application from memory** while it is in the background — together with the open document. So you need checkpoints and session recovery. * **A finger is not a mouse.** Selection, the on-screen keyboard, gestures, a compact ribbon and dialogs for a narrow screen are separate work, and it is yours. * **iOS and Android differ** in files, “Share”, offline operation and permissions. ## How the core works on a phone [Section titled “How the core works on a phone”](#how-the-core-works-on-a-phone) The store apps and the viewing kit run the same core as on a computer, so the set of operations on the phone is not separate and will not drift from the desktop one. For developers: the mobile core has one door — a request and a response as JSON strings, and the session lives between calls; it is exposed through a C interface on iOS and JNI on Android, while the browser uses a different bridge — [Phone and tablet](/sumsheet/mobile/). Where each of these is heading — [What comes next](/platform/roadmap/) and [Risks and honest boundaries](/platform/risks/). ## Next [Section titled “Next”](#next) See what it looks like The live examples open in the phone browser just as they do on a computer. [Editor](/sumdoc/demo/) · [Spreadsheet](/sumsheet/demo/) Understand the cost What you will have to do and what the contract fixes before work starts. [Pilot and acceptance](/platform/pilot/) [Embed into a web application](/start/web/)The same server path, but for the browser — and there it takes one evening. [Embed into a desktop application](/start/desktop/)If you also have a desktop program: the core runs next to it as a separate process. # Embed into a web application > First steps for a product that lives in the browser: what to take from the delivery, what to run on your side, what to put on the page — and what screen the user will see. A user of your product has a page with a list of files. Today they click “download” and leave for someone else’s program. After these steps, they will click “edit” and stay with you: the document opens right on the page, under your name, and the file never leaves your server. For the business, this means file permissions and versions stay in your system, and the user doesn’t switch between products. For the development team — the four steps described below. ## What you need to have [Section titled “What you need to have”](#what-you-need-to-have) Three things, and you almost certainly already have two of them. | What is needed | What it means in plain words | | --------------------------------- | ------------------------------------------------------------------------------------------------------------- | | A page with a list of files | The one that currently has “download”. It will get an “edit” button. | | A “who is signed in” address | Your server answers which user has come. That is your account area — it already exists. | | A “give me file number N” address | Your server hands the document itself to whoever has the right. That is your storage — it already exists too. | The editor has no accounts of its own and never will: it asks your system who has come and trusts its answer. Passwords, roles, and permissions remain yours. ## Four steps [Section titled “Four steps”](#four-steps) This section is for whoever will do the wiring. If you decide rather than wire, it’s enough to know: the editor is installed on your server as one ready-made image, and one frame is added to the page. 1. **Take the image.** The server editor ships as a ready-made Docker image: inside are the shell, the core of the same version, and everything they need; Linux x86-64, 2 GB of memory plus about 250 MB per open document. The image is in the `webhost/` folder of the release catalog — the same place as the [SumDoc builds](/sumdoc/install/) — and loads without internet access: ```bash docker load -i SumDoc--webhost-docker.tar.gz ``` 2. **Run it on your side.** One command on your server. It starts a service that listens only on the local address — it can’t be reached from outside. ```bash docker run -d --name fastdoc-webhost --restart unless-stopped \ -p 127.0.0.1:8090:8090 \ -v /srv/fastdoc-cabins:/data/cabins \ hissih/sumdoc-webhost \ --base-path /fastdoc --max-cabins 12 --idle-min 20 \ --auth-url 'https://your-host/api/me' \ --attach-url 'https://your-host/api/files/{id}/content' ``` The last two addresses are your “who is signed in” and “give me the file”. The service knows nothing else about your system. Working copies of documents live in the `/data/cabins` volume and survive an image update. Next to the archive in the release catalog is an installation guide, and inside the image is `doctor`, a check of your host against the contract. Without Docker, the service starts from the delivery archive with the same sandbox manager, only the path to the core and the dependency directory are set by hand — [Editor in the browser](/sumdoc/webhost/). 3. **Route it through your server.** An ordinary nginx proxy with one mandatory condition: **the WebSocket upgrade must go through**. Without it the editor cannot reach the core and shows an empty space. A ready sample configuration is in the delivery. The editor must open over https and **on the same domain** as your application. Otherwise the browser will not give it your cookies, and the user will see “sign-in required” instead of the document. 4. **Put the frame on the page.** Four lines where the “download” link is now: ```html ``` In place of `document-id`, substitute the file number from your own database — the one you already know. ## What the user will see [Section titled “What the user will see”](#what-the-user-will-see) They click “edit” and stay on your site. The editor opens with their document: the ribbon, pages, cursor, everything as in the familiar program. They edit a paragraph, click “save” — and the file returns to your storage as a new version. You can see what this looks like right now without installing anything: the [live editor example](/sumdoc/demo/) and the [live spreadsheet example](/sumsheet/demo/) are working programs, not screenshots. The same server editor is already embedded in \[\[var:workspace.name]] — our workspace for teams, which is also installed on your side as a Docker image. You can see it working without installing anything: sign in to the [public \[\[var:workspace.name\]\] node](https://app.layers.md) (free), create a page, drag a .docx or .xlsx into it and open it — these are the same images described above, connected to the workspace’s own “who is signed in” and “give me the file” addresses. The one thing everyone trips over The saved file arrives as `multipart/form-data` — a single part named `file`. Your handler must **parse** the multipart body, not write it to a file as is. If you write it as is, documents will be corrupted after every save — silently, without a single error in the log. This is not a hypothetical danger: the sample host in the delivery itself tripped over it. ## The same for spreadsheets [Section titled “The same for spreadsheets”](#the-same-for-spreadsheets) For Excel spreadsheets, the path is the same in spirit: the screen works in the browser, your server does the calculation. For developers — the spreadsheet web host image is in the `webhost/` folder of the SumSheet release catalog (`SumSheet--webhost-docker.tar.gz`); the launch is the same, only the image is `hissih/sumsheet-webhost` and the port is 8092: [The processor on the server](/sumsheet/server/) and [SumSheet runtimes](/sumsheet/environments/). There is also a second path that documents don’t have: **spreadsheets can calculate right in the browser**, on the user’s device. Then your server serves only the page and the file, and there is nothing to install or update on the server. What this gives and what it costs — [The core in the browser](/sumsheet/wasm/). One caveat about the second path: workbooks that fetch data from the network themselves — from databases or over `https` — are not calculated in the browser. Such workbooks are calculated by your server, via the first path. ## Further on, when the simple path is not enough [Section titled “Further on, when the simple path is not enough”](#further-on-when-the-simple-path-is-not-enough) The first steps answer the question “how to open and save”. Then the harder tasks begin, and each has its own page. | What you want to do | Where to look | | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Build a document from a template: headings, tables, headers and footers, a table of contents | [What SumDoc can do with a document](/sumdoc/capabilities/) | | Merge edits from several people, accept or reject tracked changes | [Working on a contract together](/sumdoc/capabilities/#collaborative-work-on-a-contract) | | Send one document to a list of recipients from a CSV | [Printing and publishing](/sumdoc/capabilities/#printing-and-output) | | Compute a workbook: formulas, pivot tables, data queries | [Capability map next to Excel](/sumsheet/atlas/) | | Understand what happens on which click, and add your own menu | [Responding to clicks](/sumsheet/interaction/) | | The exact names of all calls, with fields | [SumDoc reference](/reference/sumdoc/overview/), [SumSheet reference](/reference/sumsheet/overview/) | Verify in 15 minutes The core responds, your document is opened and saved — before any embedding. [SumDoc quick start](/sumdoc/quickstart/) Understand how it works Who owns what, where the boundaries run, and why the page has no copy of the document of its own. [The editor in the browser](/sumdoc/webhost/) [Embed into a desktop application](/start/desktop/)If your product is a program on a computer rather than a website: an ERP, an accounting system, your own shell.