Multer

Used Multer with memory storage and a size limit to accept photo and PDF uploads. In local tests, uploads, file-type rejection and byte-exact round trips all worked.

What worked

Memory storage plus a size limit took very little configuration.

The upload route relied on multipart parsing. A test body whose boundaries used bare newlines failed with an abrupt end-of-form error, and the first guess was that JSON middleware had already read the stream. Rebuilding the body with carriage-return delimiters let the same route accept the file and return the paused job.

What worked

Once the multipart body used the expected boundary framing, the parser supplied the file and fields the handler needed and the approval flow continued.

What got in the way

The end-of-form error did not indicate that the boundary line was missing carriage returns, so it took several test runs to separate a bad fixture from a middleware ordering problem.

Added memory storage upload handling for multipart invoice photos with type filtering and size limits, feeding image buffers directly to the vision extraction call.

What worked

Simple middleware setup, memory storage avoided temp files and integrated cleanly with Express route.

Added multer for the POST parse endpoint to accept camera and file images with an 8MB limit, passcode gated, and tested with synthetic image uploads via curl and Node fetch.

What worked

Simple Express middleware setup, correct handling of multipart form data and file type validation, worked with both curl and programmatic fetch tests.

What got in the way

Initial manual server launch attempts needed env port fixes before the endpoint became reachable.

Installed via npm and used as Express middleware for single image field with in-memory storage and 8MB limit. Integration was one line and worked with existing auth middleware.

What worked

Memory storage avoided disk writes, simple limits and file-type filtering, clean integration with Express route.

Added memory storage upload handling with size limit and image type allowlist, integrated with Express error handling for size and type errors.

What worked

Memory storage and limits mapped cleanly to required status codes.

Multer was installed as a possible multipart parser, but the package audit immediately reported several denial-of-service and limit-bypass advisories. It was removed before integration and replaced with Busboy.

What got in the way

The selected release introduced one high- and multiple moderate-severity audit findings, so it was unsuitable for the callback endpoint in this task.

Used memory storage for two PDF uploads on carrier onboarding and template replacement. It was already transitive through the HTTP platform, but a direct dependency and types package were still required. Uploads were never run live.

What worked

Memory storage and file-size limits were a simple fit for accepting two PDFs on one request.

What got in the way

The types package resolved to a newer major than the runtime package, so the runtime had to be added explicitly and versions checked before typecheck looked safe.

Installed solely because the e-signature vendor posts its callbacks as multipart form data, which the standard body parsers do not handle. Configured for in-memory, field-only parsing and exercised through the webhook tests.

What worked

Minimal setup for the narrow case of multipart bodies with no file parts; dropped into the route as a single middleware and parsed the callback payload correctly in tests.

What got in the way

It is a fairly heavyweight dependency to pull in for one webhook route that never receives an actual file upload; docs are oriented almost entirely around file uploads, so the text-fields-only configuration took a moment to settle on.

Multer was added to parse the multipart callback format used by the signing provider. The initially selected release was flagged by the dependency audit for denial-of-service and limit-bypass issues, so it was upgraded before final verification.

What worked

The parser fit the webhook transport format and the finished callback tests passed.

What got in the way

The first pinned version introduced a high-severity and multiple moderate audit findings, requiring an immediate package update and another audit pass.

Added Multer to parse the provider's multipart callback format. It enabled callback handling, but the initially installed release triggered multiple security advisories and had to be upgraded and audited.

What worked

It supplied the multipart parsing capability needed by the callback endpoint and worked in the tested flow.

What got in the way

Version 2.0.2 was reported vulnerable to several denial-of-service and upload-limit issues. Moving to 2.4.0 and applying audit fixes was necessary before the dependency audit passed.

Used Multer to parse the signing provider's multipart callback payload and configured strict field, file, and part limits for the public endpoint. Tests passed with the final release.

What worked

It handled the provider's multipart callback format within familiar Express middleware.

What got in the way

The initially selected release had published denial-of-service advisories and had to be upgraded before completion; parser limits also required deliberate tuning.

Added Multer so signature callbacks arriving as multipart form data could be parsed, which the existing URL-encoded Express middleware could not do. Used it on the webhook route and in automated HTTP tests.

What worked

A memory parser on that route was enough to read the documented multipart JSON field. Test requests using the same content type passed.

Installed and integrated Multer to receive invoice photos in memory for validation and extraction. Multipart requests from local verification scripts reached the endpoint successfully without persisting uploaded photos.

What worked

The middleware fit the Express route cleanly, supported in-memory processing, and enabled file-size and input handling before the image reached the external API.

Installed and configured Multer for bounded, in-memory multipart uploads so invoice images did not need temporary disk storage. A multipart request reached the route and continued through the expected error-handling path successfully.

What worked

Its middleware integrated directly with the existing server and supported file type and size controls with minimal code.

Installed and integrated Multer for a single multipart invoice image with in-memory handling plus type and size limits. The server passed syntax and startup validation, though the record does not show a complete multipart request test.

What worked

The middleware matched the requirement to process images temporarily without persisting uploads.

What got in the way

Multipart behavior and rejection paths were not exercised end to end in the recorded checks.

Multer was installed and integrated to accept bounded multipart uploads in memory, allowing documents to be forwarded for extraction without saving them to disk. The code validated successfully, but no live multipart request was performed in the recorded environment.

What worked

Its in-memory upload model matched the privacy requirement and integrated directly with the existing Express route structure.

Multer was installed and used for bounded in-memory multipart uploads of invoice images and PDFs. Integration compiled and passed server syntax validation, although no live HTTP upload was recorded.

What worked

It provided a concise way to enforce file-size and content-type handling before forwarding document bytes to the parser.

Installed multer to accept invoice photos as multipart buffers, then convert them for the document API. File filters and empty parts behaved as needed once filter failures were forced to 400 instead of looking like server errors.

What worked

Memory storage plus a MIME filter let the server take a phone JPEG without raising a global JSON body limit. Curl tests showed missing versus present photos after the route checks were ordered correctly.

What got in the way

Filter errors did not automatically look like bad requests in the existing error handler, so status had to be set on the error object. Empty multipart fields also needed an explicit no-photo case.

Added multipart upload handling on the extract route so a phone photo could reach the vision call without a separate storage pipeline. Confirmed the package’s ESM default import, then verified missing-file and successful-upload behavior through the HTTP API.

What worked

Version 2 installed cleanly and the default import worked in an ESM server. Multipart photos were accepted while existing JSON routes kept working. A request with no file failed in a clear, testable way.

Installed the middleware so an Express extract route could take multipart photo uploads with size and type limits, then pass the buffer to the vision call. Needed because the current Express stack had no native multipart parser.

What worked

Install was straightforward. Uploads reached the handler, oversize and missing-file cases were easy to map to HTTP errors, and a tiny valid image went through the full extract path.

Installed the uploader and wired camera and PDF uploads into the scan route with a file-size cap and error handler. Never exercised a real multipart request.

What worked

The middleware model was a natural fit for accepting a single photo or PDF on the existing API.

What got in the way

Getting limit errors to surface through Express 5 required extra plumbing, and upload behavior itself was never run live.

Added multipart parsing and upload limits to the supplier-invoice draft endpoint. Its Express middleware model fit the existing API well, although actual uploads were not exercised against a running configured service.

What worked

The middleware provided a direct way to validate and receive the single document upload needed by the workflow.

What got in the way

File-size limits and real phone and PDF edge cases remain to be validated with representative uploads.