# Envelope Wrapper

**In short:** An Envelope Wrapper puts application data inside an envelope that the messaging system accepts. The receiver removes the envelope at the destination and gets the original data back.

## Explanation

Some messaging exchanges demand a specific message format. They may require header fields or encryption. Existing systems often cannot meet those demands on their own.

The Envelope Wrapper pattern solves this. The sender wraps the application data in an envelope that the messaging infrastructure accepts. When the message arrives at the destination, the receiver unwraps it. The receiving application then gets the original data back.

**SOAP as an example.** A SOAP message has an outermost element called the envelope. Inside it sit two parts:

- A header, made of blocks. Each block may target any receiver along the message path.
- A body, which carries content for the ultimate receiver.

So the payload stays in the body, separate from the headers.

**CloudEvents as an example.** CloudEvents is a specification for describing event data in a common way. It wraps event data with context metadata, stored in Context Attributes. This works like an envelope for events. Its protocol bindings describe how events are sent and received over a given protocol. They map onto the envelopes of that transport.

For related ideas, see Message Structure, Message Translator, Content Enricher and Content Filter, and Canonical Data Model.

## Example

A legacy billing system produces plain invoice records. The company's messaging platform only accepts messages with a set of header fields. A small component on the sending side wraps each invoice in an envelope that carries those fields. The platform handles the message. A matching component on the receiving side unwraps it. The accounting application sees the same invoice record the billing system produced.

Data is wrapped before it enters the messaging system and unwrapped at the destination.

```mermaid
flowchart LR
  A[Sending application] -->|plain data| W[Wrap in envelope]
  W -->|envelope with data| M[Messaging system]
  M --> U[Unwrap at destination]
  U -->|original data| R[Receiving application]
```

## Checks

- Where a messaging exchange imposes format requirements such as header fields, the document states that application data is wrapped in a compliant envelope.
- The document states where the envelope is removed, so the receiving application gets the original data.
- Where SOAP is used, headers and payload are kept separate: headers in the envelope header, content in the body.

## Related

- [Message Structure](https://arc.fuet.ch/concepts/integration/message-structure.md)
- [Message Translator](https://arc.fuet.ch/concepts/integration/message-translator.md)
- [Content Enricher and Content Filter](https://arc.fuet.ch/concepts/integration/content-enricher.md)
- [Canonical Data Model](https://arc.fuet.ch/concepts/integration/canonical-data-model.md)
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md)
- [Messaging Protocol Support in Message Brokers](https://arc.fuet.ch/concepts/integration/messaging-systems-and-protocols.md)
- [Interoperability](https://arc.fuet.ch/concepts/quality-attributes/interoperability.md)

## Sources

- [Envelope Wrapper - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/EnvelopeWrapper.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)](https://www.w3.org/TR/soap12-part1/) — w3.org, accessed 2026-11-09
- [spec/cloudevents/spec.md at main · cloudevents/spec · GitHub](https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md) — github.com, accessed 2026-11-09
- [CloudEvents |](https://cloudevents.io/) — cloudevents.io, accessed 2026-11-09