CE ↔ KubeMQ Mapping

The CloudEvents connector is a faithful, round-tripping bridge: every CloudEvent attribute becomes a prefixed KubeMQ tag on the way in, and is reconstructed back into a CloudEvent on the way out. This page is the authoritative reference for that mapping — the attribute table, channel and ClientID resolution, how outbound messages are detected as CloudEvents, the data vs data_base64 rule, and the error surface.

Attribute mapping

When a CloudEvent is received, each of its attributes is stored as a KubeMQ message tag with a ce_ prefix. The ce_ prefix is what makes the mapping reversible: any subscriber — including CESQL routing — can read the original CloudEvent attributes off the message tags.

Auto-generation

The connector fills in missing optional attributes before validation, so a minimal CloudEvent with only type and source is accepted:

Because id is always populated, every accepted CloudEvent has a stable identifier for correlation and replay.

Channel resolution

The KubeMQ destination channel is resolved in priority order:

1. CE subject attribute — if the CloudEvent carries a subject, it is the channel name.
2. ?channel= query parameter — used only when no subject is set.

If neither is provided, the request is rejected with HTTP 400 (channel is required).

# subject sets the channel
curl -X POST http://localhost:9090/ce/send/event \
  -H "Content-Type: application/cloudevents+json" \
  -d '{"specversion":"1.0","type":"com.example.order.created","source":"order-service","subject":"orders","data":{"id":"123"}}'

# or the query parameter sets it (no subject)
curl -X POST "http://localhost:9090/ce/send/event?channel=orders" \
  -H "Content-Type: application/cloudevents+json" \
  -d '{"specversion":"1.0","type":"com.example.order.created","source":"order-service","data":{"id":"123"}}'

See Channel resolution for the full priority rules and SSE subscription behavior.

ClientID resolution

The KubeMQ ClientID attached to the message is determined as follows:

1. Auth claims — when authentication is enabled and the request carries valid credentials, the authenticated ClientID from the JWT claims overrides everything else.
2. CE source attribute — used as the ClientID when auth is off or the claim is anonymous.

This means the CloudEvent source is the effective identity for unauthenticated traffic, while authenticated traffic always carries its verified identity regardless of what source says.

Outbound CE detection

When delivering a message to a subscriber — over SSE or a queue receive — the connector inspects the message tags for ce_specversion:

Because detection is per-message, a single channel can carry mixed CloudEvent and non-CloudEvent traffic — each frame is shaped according to its own tags. Clients subscribing to such a channel should handle both cloudevent and message event types.

data vs data_base64

When reconstructing a CloudEvent for outbound delivery, the connector inspects the message body:

This follows the CloudEvents JSON format specification, where data_base64 is the standard carrier for non-JSON payloads.

CESQL attribute names

CESQL routing expressions reference CloudEvent attribute names without the ce_ prefix, even though the underlying KubeMQ tags carry it:

type = 'com.example.order.created'   -- matches the ce_type tag
source = 'order-service'             -- matches the ce_source tag

The router constructs a lightweight CloudEvent from the ce_* tags at evaluation time, so any message with ce_* tags — regardless of which connector produced it — is eligible for CESQL matching.

Error codes

All CloudEvents endpoints return a single response envelope. Errors use the same shape with is_error: true:

{
  "is_error": true,
  "message": "descriptive error message",
  "data": null
}

HTTP status codes

Common error messages

Related