Workato raises Event Streams message limits to 10MB

Larger events can pass through the stream

Workato’s 9 September 2026 changelog announces a 10MB maximum Event Streams message size across connector actions, triggers and public APIs. The previous limits were 512KB for recipes and 1MB for the API. The release also describes dynamic recipe batching with a 50MB total payload cap, with remaining messages returned in subsequent batches.

This matters when an integration carries a large structured record rather than a small change notification. It may remove a particular need to split or trim a message before publishing. It does not establish that every downstream application accepts the same payload size, or that a larger event is the right design for a given business workflow.

Sources: Workato original release

Distinguish message capacity from end-to-end delivery

The Event Streams documentation is the reference for configuring the stream and its consumers. A platform limit is one boundary in a chain that can also include a source API, recipe steps, a destination API and application-specific validation. The effective limit for a workflow is constrained by the whole path, not by its most generous component.

For example, an expanded account record may enter a stream successfully but exceed a destination’s request limit after transformation. An operator needs to know where that failure appears, whether the event can be retried and whether any earlier step already had a business effect. A successful publish response should not be used as proof that the destination accepted the intended change.

Sources: Workato Event Streams documentation

Choose between a full record and a reference

A full record can give a consumer the context captured at the time of the event. It also increases the amount of data copied, retained and potentially exposed to each subscriber. A reference can keep the event small, but the consumer may retrieve a newer state when it follows that reference. Neither design is automatically superior; they answer different temporal and operational needs.

Define whether the consumer needs the original state, the current state or a bounded set of changed fields. Include a stable event identifier, record identifier, version or effective time where the application contract supports them. Avoid adding every available field simply because the size allowance increased. Each field should have a consumer and a defensible purpose.

Test batches at realistic boundaries

Create representative events near the expected upper size, including the structure that transformations add. Test a mixed batch of small and large messages rather than only one maximum-size example. Inspect how the recipe handles subsequent batches and how the consumer preserves its progress. The release’s batching behaviour is useful, but local processing logic still needs to handle the boundaries correctly.

Include an intentionally invalid record among valid ones. Determine whether the failure blocks the batch, creates a separate exception or produces another observable outcome in the chosen recipe. Record the accepted and rejected event identifiers. A count of completed jobs alone may hide one business record that never reached its owner or a repeated record that created a second task.

Replay without repeating the business action

A network interruption can leave a producer or consumer uncertain about what completed. Test the recovery path using approved test records. If an event creates an onboarding task, updates a commercial field or initiates another consequential operation, define how a repeated delivery is recognized. Verify the actual implementation rather than assuming a stream feature supplies exactly-once business execution.

Keep an investigation trail connecting the source event, stream message, recipe run and destination result. Decide who owns an unresolved event and how long it can remain unresolved before escalation. Large messages may carry several related facts, but a single owner should still be able to explain whether the intended business action completed and what repair remains.

When the increased limit is useful

The change is relevant for teams that already have a justified large-event use case and have been maintaining size workarounds. Review those workarounds before removing them. Some may also enforce field minimization, preserve ordering assumptions or protect a smaller downstream limit. Replace only the part made unnecessary by the new capability and retain the controls that still serve a purpose.

For a new integration, begin with the smallest event that preserves the required business meaning. Measure the full path with representative volume and recovery cases before increasing scope. Workato has expanded transport capacity; the operator’s job remains to make identity, timing, delivery and downstream effect inspectable. Those properties determine whether an integration is dependable after the first successful demonstration.