Online document SDK selection: embeddable, private editing

Teams that need document editing inside their own product usually face a fork: embed an editing SDK, integrate a document suite, or build an editor. Each option carries a different kind of long-term cost.

This article focuses on the first option — an embeddable document editing SDK deployed in a private environment — and the criteria that separate a workable choice from an expensive one.

Embed, integrate or build?

• Embed an SDK. You get an editing surface and a collaboration model, then integrate it into your product’s navigation, permissions and storage. Best when documents are one capability inside a larger workflow.
• Integrate a document suite. You adopt a broader product with its own UI and account model. Fast for standard office work, less suitable when the experience must feel native to your product.
• Build an editor. Maximum control, highest cost. Only sensible when editing behaviour is a core differentiator and you can fund a long roadmap.

The distinctions matter commercially as well. Products in the WPS class are complete office suites; an embeddable SDK is a component. They solve different problems, and a component is not a replacement for a suite — nor is a suite a good fit for embedding inside someone else’s workflow.

What an embeddable SDK must provide

1. Editing fidelity

Users judge an editor against the tools they already use. Check:

• Rich text structures: headings, lists, tables, images, comments, tracked changes if required.
• Pagination and print layout, if documents are contractual or printed.
• Paste behaviour from browsers and office applications.
• Performance on long documents — hundreds of pages, large tables, many images.

Test with your own real documents, not sample files chosen by the vendor.

2. Collaboration model

Multi-user editing needs a consistency model. Two common approaches:

• Operational transformation (OT): operations are transformed against concurrent operations; strong for structured documents, requires a central authority.
• CRDT-based approaches: convergent data structures; strong for offline and peer scenarios, with different trade-offs in memory and document representation.

The right answer depends on your deployment and offline requirements. Ask how conflicts are resolved, what happens during a network partition, and how undo behaves for a single user when others are editing.

3. Format compatibility

Import and export are where projects quietly fail. Confirm:

• Which formats are supported for import, export and round-trip.
• Whether round-tripping preserves styles, comments and revision history.
• How unsupported features are handled — dropped silently or flagged.
• Whether conversion happens client-side, server-side, or both.

If your users exchange files with Microsoft Office or WPS users, round-trip fidelity deserves a dedicated test set.

4. Permissions and sharing

Documents usually inherit permissions from the host product. The SDK must support document-level roles, share links if needed, and administrative override — without duplicating your authorisation logic in a second system.

Ask where permission decisions are enforced: client, collaboration service, or storage layer. Enforcement must be server-side to be meaningful.

5. Storage and deployment

In a private deployment, document content and version history live in your object storage and databases. Clarify:

• The document representation format and whether it is exportable.
• Version history and retention controls.
• Backup and restore expectations.
• Component list, ports and egress requirements.

6. Offline and degraded networks

If users edit on unstable connections, define the expected behaviour: local draft persistence, conflict handling on reconnect, and what is visible when the collaboration service is unreachable.

7. Integration surface

The SDK should expose lifecycle events, custom toolbar actions, plugin points and theming. Check how much of your product’s UI you must rebuild versus configure, and whether upgrades can break your customisations.

Evaluation plan

A short but realistic evaluation:

1. Embed the editor in a test page inside your own application shell.
2. Import 10–20 representative documents and compare rendering with the source.
3. Run a collaborative session with 5–10 users, including a forced disconnect.
4. Attempt a permission bypass with a modified client request.
5. Export documents and verify round-trip fidelity.
6. Review the component and network requirements with your infrastructure team.

Record results against the same criteria for every candidate. Screenshots of a demo are not evidence.

Cost and roadmap risks

• Licensing model. Per-seat, per-document, per-deployment or platform licensing change the economics substantially as usage grows.
• Format maintenance. Office formats evolve; ask how compatibility updates are delivered.
• Roadmap dependency. If a required capability is “planned”, agree a contractual checkpoint or a fallback.
• Community and hiring. A widely used open-source editor reduces lock-in; a proprietary one may offer better support. Both are legitimate, but they imply different risks.

Where Feiyan Docs fits

Feiyan Docs is our online document editing SDK, designed to be embedded and deployed privately. It is currently in a Coming soon stage: we are not presenting it as available, and we do not have customer deployments to cite.

If you are evaluating this category now, use the criteria above with any candidate, including ours once a preview is available. We would rather be assessed on a working build than on a roadmap.