Skip to main content
Autype can use an existing Word document as the starting point for an API or agent workflow:
The importer reads ordered OOXML directly. It does not convert Word to HTML first. Supported content remains editable, and every normalization is returned as a structured diagnostic. There is one import path for every DOCX, including documents previously exported by Autype. The DOCX does not contain a hidden Autype document snapshot or parallel JSON representation. The importer reconstructs the editable model from native Word structures such as styles, bookmarks, field codes, section properties, headers, footers, tables and content controls. Edits made in Word are therefore always the source of truth.

​
Direct API import

Send a DOCX as multipart form data:
The response contains a complete document object accepted by POST /api/v1/dev/render. Keep document.document.type set to docx for the Word output.

​
File and MCP workflow

For an MCP client or a reusable toolkit upload:
  1. Upload the source with files_upload or POST /api/v1/dev/tools/files/upload.
  2. Call docx_import or POST /api/v1/dev/import/docx/file with its fileId.
  3. Edit the returned Document JSON.
  4. Call render_json to produce a temporary DOCX, or create a persistent document with the JSON and render that document.
Embedded raster images become protected temporary image references in the Developer API flow. They remain usable for 24 hours and are promoted to permanent organization-protected assets when the JSON is saved as a persistent document.

​
Preserved and normalized content

The importer preserves body order, headings and bookmarks, paragraphs, supported inline formatting, links, nested lists, tables, content controls, TOC fields, page and section breaks, page size/orientation/margins, columns, page-number settings, metadata, first/odd/even header and footer variants, dynamic page fields, and embedded PNG/JPEG/GIF/WebP images. Native Word captions are associated with their table, figure or code block when their bookmark and label identify that relationship. Full-page Autype decoration drawings are reconstructed as page backgrounds instead of oversized header images, and nested OOXML tables used for rich header/footer cell flows are folded back into the owning region cell. Post-table spacing and TOC field continuation paragraphs are normalized to their semantic properties so they do not accumulate additional blank space across repeated roundtrips. Native Word footnotes remain editable Autype footnotes and are emitted as native Word footnotes on DOCX export. Autype-generated charts, canvases, QR codes, and other visual elements already stored in Word as raster images roundtrip as ordinary image elements. Word features without a lossless Autype equivalent are normalized safely. For example, merged table cells are expanded into an editable rectangular grid and unsupported or active content is ignored. Native Word equations remain editable as normalized math text. Native charts, diagrams, and embedded objects use their embedded image preview when one exists; otherwise the missing preview is reported explicitly rather than silently inventing content. Endnotes and comments do not currently have a lossless Autype representation and therefore produce an explicit partial diagnostic instead of disappearing silently. The response reports all of these cases in:
  • warnings: concise human-readable messages
  • diagnostics: codes, severity, OOXML part, fallback and path where available
  • quality: exact, normalized, or partial for content, styling, and layout. The current native OOXML importer reports at least normalized for content and layout even when it needs no warnings, because editable reconstruction is not a byte- or structure-identical package roundtrip. partial identifies omitted or unsupported content; exact is reserved for a future verified lossless path.
DOCX import is semantic, not a pixel-for-pixel package clone. Content and page behavior remain editable wherever the Autype schema has an equivalent; visual or proprietary constructs are retained as images when the DOCX contains an embedded image representation. Unsupported constructs are reported explicitly instead of being kept in a hidden parallel document.

​
Limits and security

  • Maximum upload size: 50 MB
  • Maximum ZIP entries: 5,000
  • Maximum uncompressed package size: 200 MB
  • Maximum uncompressed part size: 50 MB
  • XML DTD and entity declarations are rejected
  • ZIP traversal, invalid signatures, and external image fetching are rejected
  • manage:files is required for Developer API and MCP imports
  • Imported images never expose a public object-storage URL