CloudEvents & Webhooks: The CNCF Standard

CloudEvents is a CNCF specification for describing event data in a common way. It solves the biggest headache in webhook integrations: every provider uses a different payload format.

Why CloudEvents Matters

Without a standard, every webhook provider invents its own envelope. Stripe puts the event type in type, GitHub in X-GitHub-Event, Shopify in X-Shopify-Topic. CloudEvents unifies this with required attributes: specversion, type, source, and id.

HTTP Binding: Binary vs Structured Mode

CloudEvents defines two ways to send events over HTTP:

Binary Mode

Attributes in HTTP headers, data in body. Best for existing endpoints.

Ce-Specversion: 1.0 Ce-Type: com.example.order.created Ce-Source: /orders Ce-Id: evt-abc-123 Content-Type: application/json {"order_id": "12345", "amount": 99.99}

Structured Mode

Everything in one JSON body. Simpler to log and forward.

Content-Type: application/cloudevents+json { "specversion": "1.0", "type": "com.example.order.created", "source": "/orders", "id": "evt-abc-123", "data": { "order_id": "12345", "amount": 99.99 } }

Receiving CloudEvents with Webhook

Webhook automatically detects CloudEvents by the Ce-Specversion header (binary mode) or specversion field (structured mode). No configuration needed — just point your CloudEvents source at your ingress URL.

# Send a CloudEvents webhook to Webhook curl -X POST https://webhook.sdnbros.app/a/YOUR_TOKEN \ -H "Ce-Specversion: 1.0" \ -H "Ce-Type: com.example.user.signup" \ -H "Ce-Source: /auth" \ -H "Ce-Id: $(uuidgen)" \ -H "Content-Type: application/json" \ -d '{"user_id": "u_123", "email": "dev@example.com"}'

Webhook extracts and displays:

Who Uses CloudEvents?

CloudEvents adoption is growing across the industry:

Try It Free →