Skip to main content
Attachments across the Buyer API (work orders, assets, asset types, invoices, proposals) are references into OpenWrench’s private file storage. The flow is always the same: upload the bytes first, then use the returned file reference in the entity’s attachment field. All examples assume:

​
Upload

POST /v1/buyer/file/upload is a multipart request with a single part named file, up to 512 MB:
The response (envelope type FileManager) is a FileDetails record:
Non-ASCII characters are stripped from fileName on upload. A storage-level failure returns 500; retry with backoff.

​
Reference the file from an entity

Attachment fields (for example buyerAttachments on a work order create, or attachments on an asset type) take arrays of FileDetails objects, exactly as returned by the upload:

​
Download

GET /v1/buyer/file/download/{id}/{name} streams the stored bytes with Content-Disposition: attachment. {id} is the fileId from upload (or from any FileDetails you read off an entity); {name} is the file name to serve the download as:
The response’s content type is the stored file’s own type. This is also how you pull supplier-submitted evidence: read supplierAttachments off a work order, or invoicePDFs/attachments off an invoice, and download each fileId.

​
Practical notes

  • Uploads count against the rate limit (10 requests per 20-second window), so batch-heavy migrations should throttle to roughly one upload every 2 seconds.
  • Store the fileId alongside your own records; there is no listing endpoint to rediscover files after the fact.
  • The same two-step pattern applies on the supplier side, and invoice PDFs have a dedicated supplier endpoint that uploads and publishes in one call.