A webhook 413 Payload Too Large response means the request body exceeded a size cap somewhere in your stack. The default body limits in most frameworks are conservative — 100 KB for Express, 1 MB for nginx — and modern webhook payloads can blow right past them. A Shopify order with 100 line items, a GitHub push event with 50 commits, a Stripe invoice with many line items: all routinely exceed 100 KB.
Root Causes
1. Framework body-size limit
Express's json()/raw()/urlencoded() parsers default to 100 KB. Fastify defaults to 1 MB. NestJS defaults to whatever the underlying Express/Fastify uses. Set the limit explicitly per webhook route — don't rely on defaults.
2. Reverse proxy body-size limit
nginx's client_max_body_size defaults to 1 MB and is set globally. Caddy is unlimited by default but you may have set a limit. Cloudflare Free plan caps at 100 MB; Pro at 100 MB; Business at 200 MB; Enterprise at 500 MB. AWS API Gateway is hard-capped at 10 MB and you can't raise it.
3. Provider-side payload growth
Webhook payloads grow over time as providers add fields. Stripe added invoice_settings, application_fee_amount, and others years after launch. Shopify keeps adding fields to the customer and order objects. A handler that worked for years may suddenly start hitting limits as the average payload size grows.
Fix It
// Express — raise body limit on webhook route only
app.post('/webhooks/shopify',
express.raw({ type: 'application/json', limit: '10mb' }),
webhookHandler
)# nginx — per-location body limit
location /webhooks/ {
client_max_body_size 10m;
proxy_pass http://upstream;
}# Caddyfile — explicit body limit
@webhooks path /webhooks/*
handle @webhooks {
request_body {
max_size 10MB
}
reverse_proxy app:3000
}Cloud-Provider Caps
| Service | Default cap | Adjustable? |
|---|---|---|
| AWS API Gateway (REST) | 10 MB | No (hard limit) |
| AWS API Gateway (HTTP) | 10 MB | No |
| AWS Lambda Function URL | 6 MB sync, 256 KB async | No |
| Cloudflare Workers | 100 MB | Plan-dependent |
| Vercel Serverless | 4.5 MB request body | No (hard limit) |
| GCP Cloud Run | 32 MB | No |
When You Hit a Hard Cap
If your provider sends payloads larger than your platform's hard cap (Vercel + Shopify orders is the classic), you have three options: (1) use the provider's "thin webhook" mode if available — only an event ID arrives, your handler fetches the full object via API; (2) route webhooks to a different host/service that has higher limits; (3) use a webhook gateway (Hookdeck, WebhookWhisper) that ingests the full payload and forwards a smaller summary to your serverless handler.
How to Reproduce
Use WebhookWhisper's Test Sender with a deliberately large payload (paste a large Shopify order JSON or generate one with many array elements). Fire it at your endpoint. If you see 413, you've found your cap. The error usually arrives before your handler runs, so check the reverse proxy logs first.
Frequently Asked Questions
How big can webhook payloads actually get?
Most are under 100 KB but the long tail matters. Stripe caps at ~256 KB. Shopify orders can hit 5 MB+ for huge orders. GitHub push events with 100+ commits routinely exceed 1 MB. Plan for 5-10 MB if you're integrating multiple high-volume providers.
Can I just set the limit to 'unlimited'?
Don't. An unlimited body parser is a DoS vector — anyone POSTing a 5 GB body ties up your worker. Set a sane cap (10 MB is usually plenty) and let abuse return 413 cleanly.
Vercel's 4.5 MB cap is a problem. What now?
Use Stripe's thin events, or insert a webhook gateway. WebhookWhisper or Hookdeck can ingest a 10 MB Shopify order and forward only the fields your handler actually needs.