Sometimes you need a PDF back as an editable document: a report someone wants to tweak, a form you need to fill, a table you want to pull into a spreadsheet. This shows how to convert a PDF to Word (.docx) from your own code with one request, with copy-paste examples in curl, Python, and Node.js, and the same trick for Excel.

The endpoint

Conversion is a single call: POST /v1/pdf-to-word. You send the PDF as multipart form data under a file field and get the .docx bytes back. There is no job to poll and nothing to install. The file is processed in memory and dropped once the response is sent.

curl

The quickest way to sanity-check your key and see a real .docx come back:

curl -X POST https://api.filealloy.com/v1/pdf-to-word \
  -H "X-API-Key: fa_live_your_key" \
  -F "[email protected]" \
  -o report.docx

Python

Open the PDF, post it, write the response straight to a .docx. raise_for_status() makes sure you never save an error body as a document:

import requests

with open("report.pdf", "rb") as f:
    resp = requests.post(
        "https://api.filealloy.com/v1/pdf-to-word",
        headers={"X-API-Key": "fa_live_your_key"},
        files={"file": ("report.pdf", f, "application/pdf")},
    )

resp.raise_for_status()
with open("report.docx", "wb") as out:
    out.write(resp.content)

print("Saved report.docx")

Node.js

On Node 18 or newer, fetch and FormData are built in, so there are no dependencies:

import { readFile, writeFile } from "node:fs/promises";

const bytes = await readFile("report.pdf");

const form = new FormData();
form.append("file", new Blob([bytes], { type: "application/pdf" }), "report.pdf");

const res = await fetch("https://api.filealloy.com/v1/pdf-to-word", {
  method: "POST",
  headers: { "X-API-Key": "fa_live_your_key" },
  body: form,
});

if (!res.ok) throw new Error(`Conversion failed: ${res.status}`);

const out = Buffer.from(await res.arrayBuffer());
await writeFile("report.docx", out);
console.log("Saved report.docx");

Want Excel instead?

The shape is identical. Change the path to /v1/pdf-to-excel and save the result as .xlsx, everything else in the examples above stays the same. That endpoint pulls tables out of the PDF into real spreadsheet cells rather than a flat image.

When it works well, and when it does not

This is worth being honest about, because it saves you debugging time. A native PDF (one generated from a document, where the text is real text) converts cleanly: paragraphs, headings, and simple tables come across as editable content. A scanned PDF is just images of text, so there is nothing to convert directly. If you feed it a scan you will get a document with little or no editable text.

The fix for scans is to run OCR first to add a text layer, then convert. Complex multi-column layouts and heavy formatting are also best-effort: expect the content to be right, but do not expect a pixel-perfect clone of the original design.

Handling errors

The API uses standard status codes, so you can branch on them. A 415 means what you sent was not a PDF, a 413 means the file is over the size limit, a 400 means the request was malformed, and a 422 means the PDF could not be converted (often a scan with no text layer). Check the status before writing the file, as the examples do, so a failed call never lands on disk as a broken .docx.

Summary

One multipart call turns a PDF into an editable Word document, and swapping a single word in the URL gives you Excel instead. Keep it to native PDFs for clean results, run OCR first when the input is a scan, and check the status code before saving. From there it drops straight into any backend that needs to hand users an editable file.