Generating a contract, reviewing a report, and collecting a signature sounds straightforward until you're building the backend to support it. Building document features into a web application is deceptively hard. TX Text Control has been solving that problem for .NET developers. TX Text Control .NET Server gives developers full programmatic control over document editing, processing, reporting, and PDF generation, with the flexibility to build exactly the document workflow an application needs.

But not every project starts from a .NET codebase. And not every team wants to own the document backend at the infrastructure level. That's the gap DS Server fills.

What is DS Server?

DS Server is a different product built on the same engine. Rather than embedding a library into your application code, DS Server runs as an independent, on-premise backend service. You deploy it once on Linux, Windows, containers, VMs, or bare metal, and from that point on, any application that can send an HTTP request can use it.

Your backend could be written in Python, Node.js, Java, PHP, or any other language. DS Server speaks HTTP, authenticates via OAuth, and returns documents.

It packages that engine into three core services that cover the most common document workflows:

• Document Processing: A Web API for creating documents by merging JSON data into MS Word-compatible templates, with output in PDF, PDF/A, DOCX, DOC, and RTF.
• Document Editor: A browser-based, MS Word-inspired WYSIWYG editor with a ribbon UI, track changes, document protection, and a full JavaScript API.
• Document Viewer: A lightweight viewer for sharing documents with text search, annotations, comments, and built-in electronic signature capture.

DS Server is live in minutes, either by requesting a trial token and connecting immediately, or by pulling the Docker image and running it locally. The document infrastructure is handled. Your team focuses on building the application.

So, where does this actually apply? Here are four workflows where DS Server fits naturally.

1. Automated Document Generation at Scale

Think about a platform that needs to generate customer-facing documents every day. Each document follows the same structure but contains different data depending on the customer, order, or transaction.

With DS Server, this workflow runs through the Document Processing Web API. Templates can be designed using the Document Editor with merge fields and repeating blocks, and stored as a DOCX file. When a document needs to be generated, your application sends that template to DS Server along with JSON containing the data. The API merges the two and returns a PDF, PDF/A, DOCX, and more.

What makes this especially practical is the separation between template and application code. The DOCX template is a standalone file that business teams can edit without touching the codebase or triggering a deployment. When the template changes, the output changes. The application logic stays untouched. And because DS Server runs on your own infrastructure, the data in JSON never leaves servers you control.

2. Contract Collaboration: Drafting, Reviewing, and Signing in One Place

Contracts move through multiple hands before they're finalized. A legal team drafts the document, a counterparty reviews it, stakeholders request changes, and eventually someone needs to sign. This workflow exists in nearly every industry.

DS Server makes it possible to keep that entire lifecycle inside your web application. The Document Editor embeds directly into your app as a browser-based editing surface with a ribbon UI and the document structure users expect from a word processor. It ships with ready-to-use client-side packages for ASP.NET Core, Angular, React, and JavaScript.

What matters most for contract workflows is the built-in track changes capability. Every revision is attributed to the person who made it, with a dedicated sidebar for reviewing and accepting or rejecting individual changes. This is specifically designed for scenarios where edits need to be tracked.

Once the contract is agreed upon, it moves to the Document Viewer. The user opens a read-only view, reviews the final version, and signs using the integrated signature pad. The signed document can then be exported as PDF/A, an ISO-standardized format built for long-term archival. No third-party tool is required.

3. Secure Document Sharing for Regulated Industries

In financial services, healthcare, insurance, and government, sharing documents with clients or patients isn't just a convenience feature, but it comes with obligations around data residency, access control, and auditability.

DS Server's Document Viewer is built for exactly this kind of use case. It renders documents in a responsive, mobile-friendly browser interface. Users can view and interact with the document inside your web application. They can annotate, add comments, and sign.

Access control works through OAuth security profiles. You set up one profile per application or per customer, if you're serving multiple clients from the same DS Server instance. Each profile has its own credentials and stays independent from the others.

For organizations with specific archival or regulatory requirements, DS Server generates PDF/A and PDF/A-3B natively through the Document Processing API, an ISO standard that regulators and auditors recognize for long-term preservation.

4. Embedding a Document Editor into a SaaS Product

For product teams building SaaS applications, there's a specific use case that keeps coming up: users need to create, edit, or customize documents inside the product, and the team needs to decide how to make that happen.

Building a production-grade, cross-browser, MS Word-compatible editor from scratch is a major engineering commitment. On the other hand, embedding a generic rich text widget that can't handle real document structure, such as headers, footers, page breaks, and tracked changes. This creates a gap between what users expect and what the product delivers.

DS Server provides a middle path. The Document Editor is a fully featured, Word-compatible editing component that connects to DS Server via OAuth and embeds into your web application using the client-side packages available for Angular, React, ASP.NET Core, or plain JavaScript. From the user's perspective, it's part of your product. From an engineering perspective, DS Server handles the document backend through standard HTTP endpoints.

The editor also includes built-in reporting functionality. Users can create templates with merge fields and merge blocks directly in the editor, using ready-to-use ribbon tabs and dialog boxes. Those templates can then be processed through the Document Processing API to generate finished documents at scale. This means your SaaS product can offer both interactive editing and automated document generation from a single backend.

Conclusion

Each of these workflows connects to the same underlying idea. DS Server runs as a standalone service and your application communicates with it over HTTP. There's no .NET dependency on the server side, and it works with any language on any platform. On the client side, ready-to-use packages are available for ASP.NET Core, Angular, React, and JavaScript to embed the editor and viewer directly into your UI.

That's what makes the low-code label accurate here. Not fewer capabilities, but a shorter path to using them. The same TX Text Control engine is running inside the DS Server. You just reach it through an API call instead of a library reference.

Try it yourself. Request a trial token and start sending HTTP requests immediately without any installation. Or pull the Docker image and run it locally. Either way, DS Server is live within minutes.

Frequently Asked Questions