Delivery and CloudEvents

Weik.io 2026.2

How events are stored, delivered, retried and kept apart from duplicates, how a channel with a type delivers to another system, and the CloudEvents 1.0 attributes events carry. Product page · Video

Watch: Delivery: give a channel a type, 3:12

The video gives a channel a type, and the channel delivers every event to another system.

On this page

Publishing
Reading
Retries and their delays
Handle each event once
A channel that delivers
CloudEvents
When an agent’s link is down

One event from the step that publishes it to the copies that read it, with its retries and the dead letters after its last attempt. A Weik.io installation: the hub, and the agents, which connect out to it on port 443.

Publishing#

A route publishes with to: kamelet:weikio-event-sink?channel=invoice-created. The event goes from the process to the message server beside the agent and on to the hub, and the step waits until Weik.io confirms it stored the event. When it can’t, for example while the agent’s link is down, the route’s exchange fails, so the route sees it and its own error handling decides what to do.

Reading#

Each integration that reads a stored channel gets a durable reader, which Weik.io creates when you deploy the integration:

It gets every event published since its first deploy, including those published while it was stopped.
It confirms each event once its route has finished it.
A failed event is delivered again after a delay, up to its last attempt.
The copies of the integration share the reader, so each event goes to one copy.

weikio stop keeps the reader, so a stopped integration picks up where it left off. weikio undeploy deletes it.

Retries and their delays#

The delivery block of an integration says how its events are delivered to it. Every member is optional:

invoice-archiver/integration.yaml

name: invoice-archiver
version: 1.0.0
delivery:
  retries: 10
  retryDelays: [5s, 15s, 30s, 1m, 2m, 5m]
  maxRouteTime: 10m
  inFlight: 1
  ordered: false

Member	Default	What it sets
`retries`	10	The deliveries of one event before it goes to the dead letters, from 1 to 100
`retryDelays`	`[5s, 15s, 30s, 1m, 2m, 5m]`	The wait before each retry, the last one repeating
`maxRouteTime`	`10m`	How long one event may run before another copy gets it
`inFlight`	1	How many events one copy works on at once, from 1 to 100
`ordered`	`false`	`true` delivers one event at a time across every copy, in the order they were stored

An event that still fails after its last attempt goes to the environment’s dead letters.

Handle each event once#

Every event has an ID of its own that stays the same when it is delivered again or sent again. A route whose side effect must not run twice, such as creating an invoice in the ERP, uses Camel’s Idempotent Consumer with the platform’s repository, #weikioIdempotent, which keeps one record per event for every copy of the integration:

- route:
    from:
      uri: "kamelet:weikio-event-source?channel=invoice-created"
      steps:
        - idempotentConsumer:
            header: Weikio-Event-Id
            idempotentRepository: "#weikioIdempotent"
            steps:
              - to: "{{erp-url}}/api/invoices"

An aggregator’s open batch lives in Camel’s in-memory repository. The reader confirms each event once the aggregator has it, so a restart loses the open batch. A route that must keep it uses Camel’s JDBC aggregation repository.

A channel that delivers#

A channel with a type also delivers its events to another system. The type is a Camel sink kamelet without its -sink suffix, with the kamelet’s own parameters. Slack, S3, SFTP, Kafka, JMS, HTTP and every other sink in Camel’s catalog is one document:

finance/events/invoice-alerts.yaml

apiVersion: weik.io/v1
kind: event-channel
metadata: { name: invoice-alerts, project: finance }
spec:
  type: slack
  parameters:
    channel: "#invoices"
    webhookUrl: "{{slack-webhook-url}}"

The platform writes the delivering route. A channel with a type is an integration with versions and deployments, so deploy it to the environments that deliver:

Terminal

$ weikio apply -f ./finance/events/
$ weikio deploy finance/invoice-alerts --env production

The same channel is still a stored topic that your own integrations publish into and read, and its delivery is one more reader of it.

CloudEvents#

Every event the platform stores, except an entity store write, carries its CloudEvents 1.0 attributes as ce- headers, the binary content mode of the CloudEvents binding: ce-specversion, ce-id, ce-source, ce-type and ce-time always, and ce-subject and the media type when they are known. ce-id is the event’s own ID.

A channel with a type sends its events to the sink in one of two modes:

Mode	What the sink receives
`binary`	The body as it was published, with the attributes as headers. This is the default.
`structured`	One `application/cloudevents+json` document with the attributes and the data

Terminal

$ weikio channel create finance/invoice-feed --type http --param url=https://partner.example/events --cloud-events structured

weikio get channels shows the mode in its CLOUDEVENTS column, and the admin UI’s Definition page has a CloudEvents row for a channel with a sink.

A route sets an attribute with Camel’s own header names, CamelCloudEventType, CamelCloudEventSource, CamelCloudEventSubject, CamelCloudEventTime and CamelCloudEventDataContentType, and an event source sets the type, source and subject of its events in its document. The attributes take about 300 bytes of each event.

When an agent’s link is down#

An event published into a stored channel while the agent’s link is down isn’t stored. The route’s exchange fails, so the route knows. A reader of a stored channel gets what was published while it wasn’t running once it runs again. A pass-through channel keeps nothing, so its readers miss what was published while they were away.