CloudEvents Validator

What are CloudEvents?

CloudEvents is an open specification for describing event data in a common, vendor-neutral way. It is a Cloud Native Computing Foundation (CNCF) project, and its goal is simple: when one system emits an event — an order was placed, a file was uploaded, a pull request was opened — every other system should be able to read the same envelope without custom glue code. Before CloudEvents, every provider invented its own event shape, so consumers had to learn a new format for AWS, Azure, GitHub, Stripe and everything else. CloudEvents standardises the metadata around the event (who sent it, what kind of event it is, when it happened, a unique id) while leaving the actual payload (data) entirely up to you.

A CloudEvent has four required attributes — specversion, id, source and type — plus a handful of optional ones such as subject, time, datacontenttype and dataschema. The pair source + id must be unique for every distinct event, which is what makes reliable de-duplication and replay possible. The spec is widely supported: Azure Event Grid, Knative Eventing, KEDA, Argo Events, Alibaba Cloud and many event meshes and message brokers can emit or consume CloudEvents natively, and there are official SDKs for Go, JavaScript, Python, Java, C#, Rust, PHP and Ruby.

How to work with CloudEvents

CloudEvents can travel over almost any transport — HTTP, Kafka, AMQP, MQTT, NATS, WebSockets — using one of two content modes. In structured mode the entire event (attributes and data) is encoded together, usually as a single JSON document with Content-Type: application/cloudevents+json; this is what you paste into the validator above. In binary mode the event data becomes the raw HTTP body and the metadata is carried in ce-* headers (for example ce-id, ce-source, ce-type), which keeps the payload untouched for systems that already know how to read it. Binary payloads that aren't text are carried in JSON as a Base64 string under data_base64 instead of data.

In practice you rarely hand-build the JSON: you use an SDK to construct, serialise and parse events, and your broker or gateway handles the transport binding. Validation still matters, though — a missing type, a non-RFC 3339 time, an uppercase attribute name or a relative source are common mistakes that break downstream consumers and routing rules. Paste your event above to catch them before they ship. If you receive webhooks from third parties and want to normalise them into CloudEvents, you can do it server-side with a Webhook Relay transformation function — reshape the body, set the ce-* attributes and forward the event on to any destination.

CloudEvents JSON example

A minimal but complete CloudEvent in the JSON format looks like this:

{
  "specversion": "1.0",
  "id": "A234-1234-1234",
  "source": "https://github.com/cloudevents/spec/pull/123",
  "type": "com.github.pull_request.opened",
  "subject": "123",
  "time": "2025-06-21T17:31:00Z",
  "datacontenttype": "application/json",
  "data": {
    "pullRequestId": 123,
    "title": "Add CloudEvents validator"
  }
}

CloudEvents attribute reference (v1.0)

Frequently asked questions