MAKE WEBHOOKS
Make webhook 413 — payload too large, dropped at the door
Make caps inbound webhook payload size (around 5MB). Oversized payloads get rejected outright — and unless the sender retries with a smaller payload, that event never existed as far as your scenario knows.
Why Make webhooks fail silently
Senders that embed files or blobs
Base64 images, CSV dumps, and full-record syncs blow past the limit fast.
No retry path for 413
A 413 is a client error — senders won’t retry it, and even if they did, the same payload fails again.
Intermittent size failures are the sneakiest
Most payloads fit; the occasional big one dies. You lose exactly the edge cases nobody thinks to check.
The fix
- 1
Shrink the payload contract
Have the sender post a reference (URL, ID) instead of the blob, and fetch the full object in a follow-up module.
- 2
Chunk at the source
Split large syncs into multiple webhook calls where the sender supports it.
- 3
Log rejections, not just receipts
HookShield caps and records the 413 outcome per event — you see exactly which payloads were too big instead of wondering why counts drift.
- 4
Alert on size-based rejections
A sudden 413 pattern usually means the sender changed its payload shape — catch it at the proxy, not in a reconciliation job.
DEAD-MAN'S SWITCH
Never find out about a dead webhook from a customer again
Point Make at a HookShield ingest URL. Every delivery is logged, signed, and forwarded — and if pings stop arriving, you're alerted before the silence becomes an incident.