cloudevents

Include the four required context attributes: id, source, specversion (always the literal "1.0"), and type. Add optional attributes like time, subject, datacontenttype, and dataschema as needed, and place any extension attributes flat at the top level following lowercase [a-z0-9] naming rules.

In binary mode, data goes in the transport body and each context attribute becomes a transport-native metadata field (e.g. ce- prefixed HTTP headers). In structured mode, the entire event is serialized by an event format like JSON into one body with the format's media type as content-type.

Use data_base64 only for arbitrary binary payloads, with datacontenttype naming the decoded payload's real media type. Use data for everything else: a raw JSON value for JSON media types, or a string for non-JSON content. The two members are mutually exclusive.

Yes, CloudEvents defines protocol bindings for HTTP, Kafka, AMQP, MQTT, NATS, and WebSockets. Note the header prefixes differ: HTTP uses ce- (hyphen) while Kafka uses ce_ (underscore), and datacontenttype always maps to the transport's native content-type field.

Keep the same type while data changes stay backward-compatible, and bump the type (e.g. a .v2 suffix) on breaking changes. Producers should emit both old and new types during a transition window, and update dataschema alongside incompatible changes.

Intermediaries must forward events up to 64 KiB, which is the safe interoperability floor rather than a hard ceiling. For larger payloads, keep events compact and reference data externally using the dataref extension instead of inlining it.