Enterprise integration docs are very often a .docx: internal platform teams, ERP vendors, banks and government agencies tend to author API references in Word and circulate them by email. The document has everything — endpoint tables, field lists, status codes — in a format no tooling can consume.
pdf2api accepts Word documents directly (no print-to-PDF detour) and extracts the same structured output: OpenAPI 3.1, a Postman collection, and SDK drafts.
openapi.yamlExample output (illustrative spec, not a real customer document)warnings[0] Request body is SEED-CBC encrypted — OpenAPI can't express this; implement by hand.
Word-specific messiness it deals with
Word API docs have their own failure modes, distinct from PDFs — and these are exactly where hand-transcription burns time:
- Deeply nested tables (a parameter table inside a section table inside a layout table)
- Tracked-changes leftovers and inconsistent styling between chapters written by different authors
- Endpoint definitions split across body text, tables and appendices
- Korean/English mixed terminology common in enterprise integration documents
Same pipeline, same guarantees
Under the hood a Word upload flows through the same extraction pipeline as PDFs: free preview first, one per-document payment to export, source file deleted permanently once conversion finishes. Anything the document expresses that OpenAPI cannot — signing recipes, encryption requirements — is preserved as explicit warnings rather than silently dropped.
Frequently asked questions
Which Word formats are supported?
.docx uploads up to 32MB / 100 pages, alongside PDF, PowerPoint and Excel.
My doc mixes prose and tables — will the endpoints be found?
Yes, that is the normal case. The extractor reads endpoint definitions from body text and tables together, and cross-checks them. Disagreements become warnings instead of silent guesses.
Is the document stored?
Only until conversion completes, then permanently deleted. Unpaid uploads are wiped within 24 hours.