Travel API expense report attachment upload fails with 413 error for large PDF receipts

ERP Workday
, , , , , , , ,
1

We’re hitting consistent 413 errors when uploading PDF receipts to expense reports through the Workday Travel Management REST API. Our integration automates expense report creation and attachment uploads for mobile employees. The API calls work fine for small receipts (under 2MB) but fail immediately for larger files like hotel invoices or conference receipts that are typically 3-5MB.

Error response:


HTTP 413 Request Entity Too Large
Content-Length exceeds maximum allowed: 2097152 bytes

We’ve checked the API documentation but can’t find clear guidance on attachment size limits or whether chunked upload is supported for expense attachments. This is blocking our expense submission automation and forcing users back to manual entry. Is there a way to handle larger attachments through the API, or do we need to implement file compression before upload?

2

Thanks everyone for the suggestions. After testing multiple approaches, here’s what resolved our issue:

Attachment Size Limits: The 2MB hard limit is enforced at the API gateway level for expense report attachments. This cannot be increased through configuration or API parameters. The limit exists for compliance audit performance and mobile app compatibility.

Chunked Upload Support: Workday Travel API does NOT support chunked/multipart uploads for expense attachments in R1 2024. The Content-Range header approach doesn’t work for this endpoint. Each attachment must be uploaded as a single complete file.

Expense Report Compliance Solution: We implemented a three-tier approach:

  1. Client-side compression using PDF optimization (reduces images to 150dpi, removes metadata, flattens forms)

// Compression reduces 80% of receipts to under 2MB
compressedFile = pdfOptimizer.compress(originalFile, maxSize: 2MB)
if (compressedFile.size <= 2MB) uploadToWorkday(compressedFile)
  1. Intelligent splitting for multi-page documents - upload first page as primary receipt, remaining pages as separate attachments

if (receipt.pages > 1 && receipt.size > 2MB) {
  primaryPage = extractPage(receipt, 1)
  uploadAttachment(expenseReport, primaryPage, isPrimary: true)
  supplementalPages = extractPages(receipt, 2..n)
  uploadAttachment(expenseReport, supplementalPages, isPrimary: false)
}
  1. Compliance-compliant external storage for oversized documents - upload a 1-page summary PDF to Workday containing document metadata, vendor details, and secure link to full document in approved document management system

This approach maintains audit compliance while handling 100% of receipt uploads. The compression library reduced our average file sizes from 3.2MB to 1.1MB. For the 5% of receipts that still exceed limits after compression, the splitting logic ensures the critical first page (with amount, date, vendor) is always available in Workday for approvers.

Key Configuration: Ensure your API client sets Content-Type: application/pdf and includes the expense report ID in the upload request. The attachment name should include the expense line item reference for proper association.

Our 413 error rate dropped from 23% to 0.1% after implementation. The remaining errors are now legitimate oversized files that get automatically routed to the external storage workflow.

3

Check your API version - R1 2024 introduced some improvements to attachment handling. We upgraded from R2 2023 and noticed better error messaging that actually suggests compression thresholds. Also verify your OAuth token has the correct scope for expense attachments (Expense_Reports_Attachments_Write). Missing scopes can sometimes manifest as size errors rather than permission errors.

4

The 2MB limit is intentional for compliance reasons - Workday enforces this to ensure expense attachments remain manageable for audit workflows and mobile access. However, you can work around it by splitting large PDFs into multiple attachments or using external document storage with reference links. We implemented a hybrid approach: receipts under 2MB go directly to Workday, larger documents get stored in SharePoint with a summary attachment containing the external link and key details like vendor, amount, and date.

5

I ran into this exact issue last quarter. The 2MB limit is a hard constraint on the standard attachment endpoint. We solved it by implementing client-side PDF compression before upload - reduced average file sizes by 60% without noticeable quality loss. Used a library that optimizes images within PDFs and removes unnecessary metadata. Most receipts now stay under 1.5MB.

6

Have you explored the multipart upload capability? While not explicitly documented for expense attachments, some endpoints support chunked transfers. Worth testing with Content-Range headers. Also check if your API client is setting proper Content-Type - I’ve seen cases where incorrect MIME types trigger stricter size validation.

7

I’d recommend implementing a pre-upload validation step that checks file size and type before attempting the API call. This saves API quota and provides better user feedback. For files exceeding 2MB, either auto-compress or prompt users to select specific pages. We built a simple service that extracts the first page of multi-page receipts for upload while archiving the full document separately. Reduced our 413 errors by 95%.