Webhook payload limits: why large data packets fail in automation

The problem appears later, when the same workflow starts carrying bulk updates, long arrays, generated documents, or base64-encoded files. A process that was reliable at a small scale can then fail at the transport layer, before the automation platform has a chance to run its first step.

That failure usually takes one of two forms. The receiving gateway rejects the request with HTTP 413, meaning the request body is too large. Or the upstream provider refuses to deliver an oversized event, sometimes without giving the receiving workflow a useful error to record. In both cases, the business impact is the same: the automation assumes an event exists, while the downstream system never receives the data needed to process it.

Payload limits are not an implementation detail to investigate after launch. They define what a webhook can safely carry. Once an event includes a large attachment or an unbounded collection of records, the transport design has to change.

The Anatomy of an HTTP 413 Error in Automation

HTTP 413, commonly described as “Payload Too Large,” is a server-side rejection. The receiving service has decided that the request body exceeds the maximum size it is prepared to accept. Older systems may label the same response “Request Entity Too Large,” but the operational meaning is the same.

In an automation context, the recipient is usually a gateway or trigger endpoint: a Zapier webhook, a Make custom webhook, AWS API Gateway, or an HTTP endpoint exposed by an internal service. The sender serializes the event, attaches it to an HTTP request, and sends it to the configured URL. The receiving layer measures the request body against its limit. If the body is too large, the request is rejected before the workflow's business logic runs.

That distinction matters. A 413 is not necessarily an error inside the automation scenario. The scenario may never have started. There may be no parsed JSON, no created run, no mapped fields, and no downstream execution record. From the workflow's perspective, the event is absent even though the sender attempted delivery.

The usual sequence looks like this:

1. A source system creates an event containing structured data, an attachment, or a large collection of records.

2. The source serializes the event and sends an HTTP request to the webhook endpoint.

3. The receiving gateway checks the request size before handing it to the orchestration engine.

4. The gateway returns HTTP 413 when the body exceeds its configured maximum.

5. The sender either retries, reports an error, or gives up, depending on its delivery policy.

6. The automation does not create the expected downstream record because it never received a processable event.

A retry does not solve a deterministic size violation. If the request body is 12 MB and the endpoint accepts 10 MB, sending the same 12 MB body again will produce the same result. Retries are useful for transient network failures, temporary service unavailability, and rate limiting. They are not a strategy for a payload that cannot fit through the endpoint.

A 413 error is rarely about traffic volume. It is about an automation that assumed payload size was unbounded when the platform never offered that guarantee.

The cost of the error is therefore larger than the rejected request. An event may represent a new customer, a payment status change, a release artifact, or a batch of records that other systems depend on. If the sender does not maintain a durable delivery queue, the event can disappear from the workflow's normal audit trail. Engineers then have to compare the source system with the destination to find what failed.

The shape of the data is often more important than the number of top-level fields. A compact-looking JSON object can contain a large nested array. A single document can dominate the entire request body. A binary file encoded as base64 becomes larger again because the binary content is represented as text. That is why a webhook that normally carries a small event can fail when one customer uploads an image, a PDF, or a spreadsheet.

It is also useful to distinguish the payload body from the total HTTP message. Providers may describe their threshold in terms of request size, body size, or a platform-specific representation of the event. The practical rule is not to design exactly up to the documented maximum. Leave room for serialization overhead, optional fields, and future changes to the event schema. A payload that is technically under the limit today may cross it after a new field or a larger array is introduced.

Platform-Specific Thresholds: Zapier, Make, and AWS API Gateway

The exact ceiling depends on where the request enters the system. A workflow may pass through more than one limit: the source provider's webhook maximum, the iPaaS trigger limit, an internal gateway, and the limits applied to later API actions. The smallest limit in that chain determines what can be delivered reliably.

The commonly documented thresholds for the platforms discussed here are:

These values should be treated as transport constraints, not as recommended operating targets. Platform documentation can change, and different products within the same vendor may apply different limits. A workflow that depends on a specific threshold should verify the current documentation and test the complete delivery path, not only the final application endpoint.

Zapier

Zapier's webhook limits are asymmetric. The documented maximum for webhook triggers is 10 MB, while webhook actions have a 5 MB limit. That difference matters when a Zap both receives and sends HTTP data. An inbound event may fit through the trigger and then fail when a later action attempts to forward a larger body to another service.

The action limit is particularly easy to miss in a multi-step workflow. The first step receives a compact notification, a later step enriches it with related records, and a final step sends the resulting object to another endpoint. The payload may grow during transformation even though the original trigger was small. The failure then occurs at the outbound action rather than at the beginning of the Zap.

The safe design is to avoid using a webhook action as a bulk transport mechanism. Send identifiers, URLs, and metadata instead. Retrieve the larger object through an API or a file-transfer endpoint where the transfer can be retried and monitored independently.

Make

Make applies a 5 MB limit, documented as 5,242,880 bytes, to the relevant webhook body. The important detail is that the limit concerns the raw HTTP body rather than the amount of data the scenario eventually extracts from the parsed JSON.

A scenario can therefore fail before filters, routers, iterators, or error handlers have a chance to run. Adding another route inside the scenario does not help because the request has already been rejected at the webhook boundary. Nor does moving the large field to a later module help if the field is still included in the incoming request.

This is also why counting only the visible business data can be misleading. JSON punctuation, field names, escaping, nested structures, and encoded binary content all contribute to the transmitted body. When the event is close to the limit, measure the serialized request rather than relying on the size of an object displayed in an application interface.

AWS API Gateway

AWS API Gateway enforces a fixed 10 MB limit for request and response payloads in the relevant API Gateway path. API Gateway resource policies do not raise this limit. Changing authorization rules, adding a resource policy, or moving the route within the API does not turn the gateway into a large-file transport.

That makes the architectural decision straightforward: a request that can exceed 10 MB must not depend on API Gateway accepting the complete body. The application can receive a small event containing an object key, a signed URL, or a record identifier, then retrieve the large content through a storage or application endpoint designed for it.

This distinction is important for public webhook receivers. API Gateway can still be an excellent entry point for authentication, request validation, throttling, and routing. It simply should not be treated as an unlimited pipe. If the body may contain a document, media file, or large export, the gateway should receive a reference to that object rather than the object itself.

GitHub webhooks

GitHub's documented webhook payload limit is 25 MB. For payloads exceeding that limit, GitHub drops the delivery instead of sending an oversized request to the receiver. That is a different failure mode from a visible 413: the receiving automation may never see an HTTP request to reject.

The practical consequence is that a GitHub webhook receiver cannot depend on the sender's delivery attempt as proof that the event arrived. A repository event that produces a very large payload needs another recovery path. Depending on the use case, that may mean querying the GitHub API for the relevant resource, running a scheduled reconciliation, or designing the integration around a smaller event and a follow-up fetch.

The limit also makes event selection part of payload design. If a provider offers several event types, choose the one that contains the smallest useful notification and retrieve details later. Do not assume that a higher plan or a different gateway policy will increase GitHub's payload ceiling.

The Hidden Risks of Silent Delivery Drops and Truncation

A 413 is visible. It produces a status code and often leaves a trace in gateway logs or the sender's delivery history. Silent delivery loss is more difficult because the receiving system may have no failed run to display.

For GitHub, the relevant boundary is payloads above 25 MB: those deliveries are dropped rather than delivered as oversized requests. The receiver cannot handle an event it never receives. Recovery therefore depends on an independent signal, such as a source-system query, an event sequence, or a reconciliation process.

Truncation creates a different problem. A provider or intermediary may deliver only part of a body, or may limit the number of records included in an event. When the result remains syntactically valid JSON, the receiving workflow can mark the run as successful even though the data is incomplete. The absence of an exception becomes the dangerous part.

Consider a bulk update with a collection of line items, contacts, or transactions. If the automation receives fewer items than the source says it should have, it may still create a valid-looking destination record. Every individual field can pass validation. The data is wrong because the collection is incomplete, not because the JSON is malformed.

This is where webhook data truncation issues become operational rather than merely technical. A malformed request tends to fail loudly. A valid but incomplete request can pass through every normal success metric:

• The webhook endpoint returns a success response.
• The iPaaS run appears completed.
• Field mappings resolve without errors.
• The destination API accepts the record.
• No one notices that part of the source collection is missing.

A workflow that handles a fixed number of records can hide this problem for a long time. As the source dataset grows, the missing portion becomes more significant. The system does not necessarily fail on a particular record; it fails by quietly reducing the completeness of each batch.

The defense is to validate both structure and cardinality. A schema check can confirm that required fields exist, but it cannot prove that every expected item arrived. For collections and bulk events, add checks such as:

• Compare the source-reported count with the number of received records.
• Preserve a batch ID or event ID that can be used to query the source later.
• Reject or quarantine an event when a required collection is incomplete.
• Record the source version, sequence number, or updated-at value when available.
• Reconcile the destination with the source on a schedule rather than trusting individual deliveries.
• Alert on missing batches and count mismatches, not only on failed HTTP requests.

Reconciliation is especially important when the provider does not guarantee replay. A scheduled comparison can discover that an expected object never arrived, that a batch contains fewer records than the source, or that an event was processed twice. It changes the question from “Did the webhook run?” to “Does the destination agree with the source?”

That is a more useful measure of reliability. A green workflow run is evidence that the workflow executed. It is not evidence that the business event was complete.

Architecting Around Limits: The Thin Webhook Pattern

The thin webhook pattern is the most practical response to webhook payload size limits in automation. The webhook carries a notification, not the complete business object. The receiving workflow uses that notification to retrieve the current data from the source system.

A thin event might contain:

• an event or resource ID;
• the resource type;
• the event type, such as created or updated;
• a timestamp or sequence value;
• a link or API path for retrieval;
• a tenant, account, or workspace identifier;
• a signature or verification data needed to authenticate the event.

The body stays small because it contains references and metadata rather than a large nested object. The automation receives the event, verifies it, extracts the identifier, and makes an authenticated API request for the full record.

The pattern changes the reliability profile in several useful ways.

First, it separates notification delivery from data transfer. The webhook only needs to announce that something changed. The API request handles the larger representation through a channel that can have its own timeout, pagination, retry, and error handling.

Second, it makes retries more meaningful. If the retrieval request fails because of a temporary API error, the automation can retry the fetch without asking the source to resend a potentially oversized webhook. If the record changes between notification and retrieval, the workflow can use the event timestamp or version to decide which representation it should process.

Third, it supports pagination. A record with a large collection does not have to be returned as one enormous response. The automation can fetch the first page, follow the pagination cursor, and process the collection in controlled portions. This is a better fit for managing large JSON payloads in iPaaS systems than passing one deeply nested document through every module.

The pattern is not free of trade-offs. It introduces a dependency on the source API's availability, authentication, rate limits, and consistency model. A webhook can arrive before the updated resource is visible through a read endpoint. The source API may throttle a burst of fetches. A deleted object may no longer be available by the time the workflow attempts retrieval.

These are manageable problems, but they need explicit handling. A production implementation should consider:

1. Idempotency. Store the event ID or resource version so that a retry does not create duplicate downstream records.

2. Backoff. Retry temporary API failures with increasing delays rather than sending a burst of identical requests.

3. Pagination. Process large collections page by page and preserve the cursor if the workflow can resume.

4. Authentication. Keep API credentials separate from event data and validate webhook signatures where the provider supports them.

5. Ordering. Decide whether an older event can overwrite a newer representation when deliveries arrive out of order.

6. Deletion handling. Preserve enough information in the event to process a deletion even when the source record is no longer retrievable.

7. Reconciliation. Query the source independently so a missing webhook does not become a permanently missing record.

The additional round trip usually matters less than the transport risk it removes. A background CRM sync, ERP update, document workflow, or marketing automation process generally benefits more from predictable recovery than from shaving a small amount of latency from a single event. The exception is a genuinely latency-sensitive system where the source API cannot provide the required timing or consistency. In that case, a durable message or object-transfer architecture is usually more appropriate than a larger webhook.

Implementing URL Hydration for Large Data Transfers

A thin webhook works when the source exposes the full record through an API. It is less useful when the event contains a generated file, a binary object, or a large export that does not have a practical record endpoint. For those cases, URL hydration moves the large data out of the webhook and gives the automation a reference to retrieve it.

The sequence is simple:

1. The upstream system creates or receives the large object.

2. It stores the object in object storage or another file-transfer service.

3. It generates a time-limited signed URL or an equivalent access token.

4. The webhook sends the URL together with the object ID and event metadata.

5. The receiving workflow downloads the object from that URL.

6. The workflow validates, processes, and records the result.

7. The object or URL is retained according to the required retention and audit policy.

The webhook remains small because it carries a pointer rather than the file. The large transfer takes place over infrastructure intended for large objects instead of through an iPaaS trigger that has a strict request limit.

The reliable way to move a large file through an automation pipeline is to move a reference through the webhook and the file through a separate transfer path.

Signed URLs are useful because they can grant temporary access without exposing permanent storage credentials to the receiving workflow. They also make the transfer independently observable. The downloader can record whether the URL was fetched, whether the response had the expected content type and length, and whether the checksum or other integrity check passed.

Several details determine whether the pattern is dependable.

Expiration and retries

A URL that expires too quickly can turn a temporary queue delay into a permanent download failure. The expiry window must account for workflow scheduling, queue time, provider latency, and the slowest expected download. At the same time, the URL should not remain valid indefinitely if the object is sensitive.

If a download fails after the URL expires, the workflow needs a way to request a fresh URL. A retry that reuses an expired URL is not a recovery strategy. Store the object ID or source reference so the automation can obtain a new link when necessary.

Integrity checks

A successful HTTP response does not prove that the complete file arrived. Where the source supports it, compare the received content length with the expected size and validate a checksum or other integrity marker. For documents and exports, also validate that the content can be opened by the next processing step.

This matters because large transfers can fail in ways that are not represented by a clean application error. A connection may terminate after part of the content arrives, or an intermediary may return an error document with an unexpected status. The workflow should not mark the business event complete until the downloaded object passes its basic integrity checks.

Access control

A signed URL should be scoped as narrowly as the storage system allows. Limit the object, the permitted operation, and the lifetime. Avoid placing long-lived credentials in a webhook body. Treat URLs as secrets while they are valid: they may grant access to the underlying file to anyone who obtains them.

The webhook can also carry a non-sensitive object ID while the receiving service obtains the signed URL through an authenticated API call. That adds a request, but it reduces the amount of privileged information moving through the event path.

Processing and storage

The automation should not assume that a file can be loaded entirely into every intermediate step. Large objects may need streaming, temporary storage, or a dedicated processing service. An iPaaS workflow can orchestrate the process while a specialized service performs conversion, extraction, scanning, or media processing.

The same principle applies to bulk exports. Instead of embedding a large CSV or JSON document in the webhook, publish the export as an object, send its location, and let the receiving process download it in a controlled way. This improves observability and gives the transfer its own retry and retention rules.

URL hydration is not a workaround for every kind of data. It requires the upstream system to create and expose the object, and it requires the receiver to fetch it within the access window. But for generated documents, media, binary attachments, and large exports, those are the right responsibilities to separate. The webhook announces availability; the file-transfer path carries the file.

Designing for the Limit Before It Becomes an Incident

The most useful payload limit is not the maximum printed in a vendor table. It is the maximum size the complete workflow can handle with room for growth, retries, logging, and schema changes.

Start by mapping the full delivery chain. Identify the source webhook limit, the trigger limit of the iPaaS, any API gateway in front of an internal service, the limits on outbound actions, and the maximum response size of the APIs used for hydration. A payload that passes the first boundary can still fail later when a transformed object is sent to another endpoint.

Then measure realistic serialized events. Test the smallest normal payload, the largest expected record, the largest collection, and the largest supported attachment. Include escaped characters and base64 encoding where they are part of the real integration. Testing only a representative small event provides false confidence.

The architecture should also define what happens when a payload is too large:

• Can the sender retry with a smaller representation?
• Can the receiver fetch the full record from an API?
• Is there a durable queue or outbox that preserves the event?
• Can the source regenerate a signed download URL?
• Will the workflow detect a missing delivery through reconciliation?
• Which system owns the status of the transfer?
• Can an operator replay the event without creating a duplicate?

These questions turn payload handling from an undocumented assumption into an explicit part of the integration contract.

For most business automations, the default should be conservative: send a thin event, fetch the current resource, paginate large collections, and use signed URLs for files. Reserve full embedded payloads for small, bounded objects whose maximum size is known and enforced. If a field can grow without a defined upper bound, it does not belong in the webhook by default.

Webhook payload limits are a constraint on system design, not merely a number in platform documentation. Zapier, Make, AWS API Gateway, and GitHub all impose ceilings, and their failure modes are not identical. A 413 can stop a workflow before it starts. A GitHub delivery above 25 MB can be dropped before the receiver sees it. A truncated collection can produce a successful run containing incomplete business data.

The robust response is to reduce what the webhook carries. Use identifiers and metadata for ordinary resource changes. Hydrate the full object through an API. Move binary data and large exports through object storage or another dedicated transfer path. Add count validation, idempotency, and reconciliation so that a missing or incomplete delivery becomes visible.

A webhook is a notification channel. Treating it as a general-purpose file pipe works only while the data remains small. Once the payload can grow, the reliable design is to send the pointer through the webhook and move the data through a channel built to carry it.