Greenhouse 413 payload too large attachment

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

Check each attachment entry has content (base64), type, filename. Fix: host large files and link them instead of attaching.

Steps

1. Symptom: 413 content too large on /mail/send, usually right after adding attachments.
2. Remember base64 inflates files by about a third. A 20 MB file is ~27 MB on the wire before the rest of the JSON.
3. Check each attachment entry has content (base64), type, filename. A missing type or a double-encoded file bloats or breaks the payload.
4. Fix: host large files and link them instead of attaching. Attachments are for small files the recipient must have offline.
5. Compress or downscale before attaching: PDFs, images, and decks usually shrink a lot.
6. If you must send big, split across messages rather than one giant request.
7. Over SMTP the same problem surfaces as 552 (message larger than the system limit). Same fix.

When to use

You are seeing this: Symptom: 413 content too large on /mail/send, usually right after adding attachments. Use this skill when you run into "SendGrid 413 content too large: attachments blew the request size".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Remember base64 inflates files by about a third.

The errors doc lists 413 as content too large. The mail send reference documents attachments as base64 content with type, filename, and disposition. The SMTP errors doc lists 552 for messages larger than the system limit. Sources: https://docs.sendgrid.com/api-reference/how-to-use-the-sendgrid-v3-api/errors | https://docs.sendgrid.com/api-reference/mail-send/mail-send | http://sendgrid.com/docs/Glossary/emailerrormessages.html

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.