Assembly and Page Surgery

Five endpoints cover the mechanical half of PDF work: combining, cutting, rearranging, de-encrypting, and crossing between images and PDF. They are deliberately deterministic, no model in the loop, so they are fast, exact, and safe to run unattended at any volume. Everything takes the shared input contract (base64 or file id) and returns its result as a file id ready to chain.

1Merge: many into one#

POST /lmkit/v1/pdf-merge concatenates two or more sources in the order given, each a base64 document or a file id, freely mixed. Assembling a dossier from segments the IDP pipeline produced, prepending a generated cover page from image-to-pdf, or stitching per-chapter exports into one deliverable is one call.

2Split and edit: cutting and rearranging#

• POST /lmkit/v1/pdf-split cuts one document into parts by 1-based page ranges, one output per range ("1-3", "5", "7-"). This is the DETERMINISTIC split, for when the cut points are known; when they must be discovered from content, that is intelligent splitting, and the two compose: discover boundaries once, then cut by ranges forever after in a fixed workflow. With split_mode: "BlankPages" the same endpoint cuts a batch scan on its blank separator sheets instead: the runs of non-blank pages become the parts and the separators are omitted. blank_tolerance (default 10) absorbs scanner noise, a uniformly dark page never counts as blank, and no AI model is involved.
• POST /lmkit/v1/pdf-edit rebuilds the document from a declarative page list: each entry names a zero-based source page_index and an absolute rotation (0, 90, 180, 270). One shape expresses every page operation: reorder by listing in a new order, drop by omitting, duplicate by listing twice, rotate by setting the angle. Declarative beats operation sequences precisely because the request IS the resulting document, reviewable at a glance.

3Unlock: de-encrypting your own inputs#

POST /lmkit/v1/pdf-unlock returns an unprotected copy of a password-protected PDF, given the password. Its job is workflow hygiene: upstream systems deliver encrypted files, and carrying a password through every later call is worse than shedding it once at the door. (Most endpoints, including redaction and PDF/A conversion, also accept a password directly when a one-shot operation is all you need.)

4The image bridge#

• POST /lmkit/v1/image-to-pdf packs one or more images into a PDF, in order, with the compression choice (image_encoding, jpeg_quality) and target pdf_version exposed. The classic uses: normalizing photographed documents into the format the rest of the pipeline speaks, and building cover sheets or exhibits from rendered images.
• POST /lmkit/v1/pdf-to-images rasterizes pages the other way: jpeg, png, or tiff, at 72 to 600 DPI, over an optional page range. Multiple pages arrive as a ZIP; unwrap_single stores a lone page as a plain image file; and multipage: true packs every page into ONE multipage TIFF, the shape fax pipelines and legacy archival systems still demand.

An image-to-PDF result is a picture of a document, not yet a document: OCR overlay is the next call when the output must be searchable.

5Stated plainly#

• Merge, split, and edit are deterministic and declarative: the request states the output, so the operations are safe to automate blind.
• Known cut points belong here; discovered cut points belong to intelligent splitting, and the two are complementary stages, not competitors.
• The image bridge runs both directions with production knobs (DPI, formats, multipage TIFF), and pairs with the OCR overlay when pixels must become text.