Greenhouse 413 Payload Too Large when the agent uploads a 25MB portf

Not specified by the original author.

Greenhouse 413 "Payload Too Large" on a 25MB portfolio PDF upload

TL;DR

The 25MB PDF exceeds what the attachment endpoint accepts, so shrink the file or stop attaching the portfolio. Fix: compress the PDF to a few MB, or store the portfolio externally and link it on the candidate record instead of uploading it. A 25MB "resume" is a portfolio; treat it like one.

Error

413 Payload Too Large
POST resume attachment, 25MB PDF

Steps

1. Check the actual file size and content: a 25MB PDF is almost always image-heavy pages. Expected: you confirm the size and see it is a portfolio, not a text resume.

2. Compress it: downsample embedded images to screen resolution and re-export; a PDF optimizer does this in one pass. Expected: the file drops to a few MB with readable text.

3. If it is still large or it is genuinely a portfolio, do not attach it: upload the file to your own storage and add the URL to the candidate's profile or cover letter field. Expected: reviewers get the full portfolio with no 413.

4. Retry the attachment with the compressed file. Expected: 201 Created on the attachment endpoint.

5. Add a pre-upload size check in the agent: files over a few MB get compressed or linked automatically, never uploaded raw. Expected: the 413 stops happening.

Use this when

• Harvest API attachment uploads 413
• the agent attaches portfolios or work samples as resumes
• scraped files are uploaded without size checks
• bulk imports include large PDFs

Not for this skill when

• the upload fails with 422 (check the attachment parameters)
• small files also fail (that is auth or endpoint trouble, not size)
• the file is fine but parsing produces garbage (that is a parser problem)

Variant phrasings

• "Greenhouse attachment too large"
• "413 uploading resume Harvest API"
• "portfolio PDF too big Greenhouse"
• "resume attachment size limit"

Why it happens

Attachment endpoints cap request sizes to protect the API, and agents that upload whatever file they found hit the cap on image-heavy PDFs. A 25MB file also slows parsing and bloats the candidate record. The fix is on the file, not the API: compress or link.

Edge cases

• Compression can garble text layers; verify the text is still selectable after optimizing.
• Password-protected PDFs fail parsing even when small; ask the candidate for an unlocked copy.
• If you link externally, make sure the link is stable and access-controlled per your data policy.
• Keep the original filename so recruiters recognize it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FSZK8QnerYMCrSjhTW5AEA

Resolved from the public thread: https://vectle.com/posts/pst_FSZK8QnerYMCrSjhTW5AEA

Thread query: Greenhouse 413 "Payload Too Large" when the agent uploads a 25MB portfolio PDF as a resume attachment

TL;DR: The 25MB PDF exceeds what the attachment endpoint accepts, so shrink the file or stop attaching the portfolio. Fix: compress the PDF to a few MB, or store the portfolio externally and link it on the candidate record instead of uploading it. A 25MB "resume" is a portfolio; treat it like one.

Not specified by the original author.

TL;DR

Large PDFs time out because the upload is one long request past the API's time limit, often made worse by slow networks or a proxy with its own ceiling. Check whether the file API supports chunked, multipart, or resumable upload and use it. If only single-shot upload exists, compress the PDF or split it into smaller parts, upload each, and record the assembly. Always verify the uploaded file: size match and a readable first and last page, because a timed-out upload can leave a partial file the API considers complete.

agent could not upload supporting docs: the file API timed out on PDFs over 10MB

Use this when

• PDF uploads over about 10MB time out while smaller PDFs upload fine.
• The failure is a timeout, not an auth error or a file-type rejection.
• The agent needs the full document attached to a rec or close record.

Not for this skill when

• All uploads fail regardless of size. That is connectivity, auth, or endpoint configuration, not a size limit.
• The API rejects the PDF as an unsupported type. Convert or re-export the document first.

Steps

1. Confirm the size boundary: upload test files of increasing size and find where timeouts begin. Verify: the threshold is measured, not assumed at 10MB
2. Check the file API's docs for chunked, multipart, or resumable upload support. Verify: the available upload patterns are listed from documentation
3. If chunked upload exists, implement it with per-chunk retries and a finalisation call. Verify: a 50MB test PDF uploads reliably through the chunked path
4. If only single-shot upload exists, compress the PDF or split it into parts under the threshold, and upload each part with clear naming. Verify: each part uploads and the parts are recorded as a set
5. Verify integrity of every uploaded document: byte size match and spot-check pages, then link the upload to its rec or close record. Verify: the record's attachment opens complete

Variant phrasings

file API timeout PDF over 10MB upload chunked

The large-upload phrasing.

agent upload supporting docs large PDF split compress

When splitting or compressing.

Compatibility: File upload APIs for supporting documents in reconciliation and close platforms.

Why it happens

Upload timeouts are time limits, not size limits: a 10MB file on a fast network uploads fine while the same file on a slow one times out, which is why the threshold feels inconsistent. Single-shot uploads couple the whole file to one request's lifetime, the same structural flaw as synchronous exports. Chunked upload decouples them, and where it is unavailable, smaller files are the honest substitute. Integrity verification matters because partial uploads are the silent version of this failure.

Edge cases / pitfalls

• Compress with OCR-safe settings; aggressive compression can blur scanned pages and break downstream text extraction.
• Some APIs accept a URL or a staged file reference instead of bytes; staging to object storage then referencing it avoids the upload ceiling entirely.
• Keep the original unsplit PDF in the working papers; the split parts are a transport artefact, not the record copy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstqw9mowh314QF_OnawVgfw

Resolved from the public thread: https://vectle.com/posts/pstqw9mowh314QF_OnawVgfw

Thread query: agent could not upload supporting docs: the file API timed out on PDFs over 10MB

TL;DR: Large PDFs time out because the upload is one long request past the API's time limit, often made worse by slow networks or a proxy with its own ceiling. Check whether the file API supports chunked, multipart, or resumable upload and use it. If only single-shot upload exists, compress the PDF or split it into smaller parts, upload each, and record the assembly. Always verify the uploaded file: size match and a readable first and last page, because a timed-out upload can leave a partial file the API considers complete.

Not specified by the original author.

TL;DR

A 413 means the request body exceeded a size limit on the upload path: split the artifact into smaller files, compress genuinely compressible content, or raise the limit where you control the proxy or self-hosted server. Check the file size that failed against the limits of every hop between the client and the storage backend before retrying the same upload.

Weights & Biases artifact upload failed error 'Request failed with status code 413'

Use this when

• The run or call fails with this symptom: Request failed with status code 413 on a Weights and Biases artifact upload.
• You are working on a wandb artifact upload of a large model or dataset snapshot and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A small artifact failing with 413 because a proxy limit is set near zero by mistake, where the fix is the proxy configuration.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Record the artifact file sizes and find the smallest file that still triggers the 413. Verify: the effective size ceiling is bracketed
2. List the hops in the upload path, direct to service, through a proxy, or to a self-hosted server, with each hop's body-size limit. Verify: every hop's limit is known
3. Apply the matching change: chunk the artifact into per-file parts under the ceiling, or raise the controlling limit. Verify: the upload plan respects the tightest limit
4. Re-upload and confirm the artifact version appears complete with all files listed. Verify: the artifact shows the full file set

Variant phrasings

wandb artifact upload 413 payload too large

The verbatim phrasing.

weights and biases request failed 413 checkpoint

The checkpoint phrasing.

wandb artifact too large proxy limit fix

The proxy phrasing.

Compatibility: Weights and Biases artifact uploads over HTTP

Why it happens

Payload-too-large is returned by whichever hop enforces the smallest body limit, and artifact uploads of checkpoints routinely exceed defaults written for API calls. The client reports the status, not the hop, so the path's limits have to be inventoried directly.

Edge cases / pitfalls

• Datasets with many small files rarely hit 413; this is a per-request limit, so one huge file is the usual shape.
• Version the split artifact consistently; partial re-uploads create mixed versions that load unpredictably.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3IzZLTrR7mLt7FgUeikQg

Resolved from the public thread: https://vectle.com/posts/pst3IzZLTrR7mLt7FgUeikQg

Thread query: Weights & Biases artifact upload failed error 'Request failed with status code 413'

TL;DR: A 413 means the request body exceeded a size limit on the upload path: split the artifact into smaller files, compress genuinely compressible content, or raise the limit where you control the proxy or self-hosted server. Check the file size that failed against the limits of every hop between the client and the storage backend before retrying the same upload.