Multimodal signature API

01 Problem and context

In most administrative workflows, signing a document still means printing, signing by hand, scanning, and re-uploading. Existing platforms that address this force documents outside the organization, creating a dependency on third-party services.

In most administrative workflows, signing a document still means printing it, signing by hand, scanning and uploading it again. This API removes that detour: it takes a document and a signature, whether drawn on screen, typed in a cursive face or uploaded as an image, and returns the signed file as PDF or DOCX. It is deterministic document composition, not cryptography: the service inserts the visual mark, and says so plainly.

02 Solution

A single-endpoint API that receives the document and signature (drawn strokes, cursive text, or image) and returns the signed file in PDF or DOCX format. The injection engines are decoupled by format, so supporting a new one only requires adding an engine without modifying the router. It is deterministic document composition rather than cryptography: it injects the visual mark and is declared as such.

1. 01Document engine research before any code: PyMuPDF for PDF, chosen for deterministic insertion at absolute coordinates, and python-docx for Word as the stable OOXML standard.
2. 02The finding that reshaped the design: a DOCX has no coordinates, it is a text flow. The rule was written down before it was implemented: for DOCX the requested position is ignored and the signature is appended, so the XML schema is never corrupted.
3. 03Client-side coordinate normalisation, because the PDF origin shifts depending on page rotation.
4. 04Multimodal capture in the browser with a canvas and SignaturePad, which emits base64 PNG and keeps vector stroke processing off the server.
5. 05Three-layer architecture with injection engines decoupled per format: supporting a new format means adding an engine rather than touching the router.
6. 06Minimal surface: a single endpoint with a JSON contract in and out.
7. 07Dual packaging for serverless and containers, plus a handshake script that checks the engines are operational.

03 Results

Verifiable figures in the repository and its documentation:

04 How it's built

Web system for signing PDF and DOCX documents using signatures captured via three methods: canvas strokes (SignaturePad), cursive text fonts, or uploaded images. The FastAPI backend routes by MIME type to injection engines based on PyMuPDF (absolute coordinate positioning in PDF) and python-docx (text-flow insertion in Word), exchanging Base64-encoded documents. Includes a static vanilla JS frontend with previews via pdf.js and draggable positioning.

05 Ethical decisions

• ✦The service does not present itself as an advanced electronic signature. It injects the visual representation of a signature, performs no cryptographic operation, issues no certificates and guarantees no non-repudiation. Saying so prevents anyone from assigning it legal weight it does not carry.
• ✦There is no persistence layer: no database, no signature store, and the signature image is neither kept nor reused.
• ✦Processing passes through temporary files. That is an accepted consequence of the architecture rather than an oversight, and it is documented alongside what would still be needed for genuinely sensitive documents.

06 Highlights

• ✦Three signature capture modes: touch or mouse drawing (SignaturePad), typographic generation with cursive fonts, and image upload.
• ✦PDF injection via absolute coordinates using PyMuPDF while preserving metadata, and DOCX injection via text flow using python-docx.
• ✦Documented layered architecture (frontend, API router, injection engines) with SOPs in the architecture/ folder.
• ✦PDF preview via pdf.js and draggable signature positioning with interact.js, including touch calibration for mobile devices.
• ✦Ready for serverless deployment on Vercel and Docker containers, complete with test and environment verification scripts.

07 Limitations

There is no dataset and no trained model; the limits are about scope and file handling. For DOCX the requested position is ignored by design, because the format is a text flow and forcing coordinates breaks the XML. Processing writes both the payload and the result to the system temp directory, and the code does not explicitly delete them afterwards: acceptable on ephemeral serverless infrastructure, not on a long-lived server without adding cleanup. Format detection relies on MIME type and extension rather than on the binary content signature.