Events and CloudEvents

When one integration publishes an event to a channel, any number of others can react to it, and a new reader joins without a change to the publisher. A reader that was stopped gets what it missed when it starts again, and an event a reader keeps failing goes to the dead letters, where you resend it. Every stored event carries its CloudEvents 1.0 attributes, and a channel can also deliver its events to systems such as Slack, S3 or Kafka. Event sources bring events in from queues, webhooks and folders, and change tracking turns changes in PostgreSQL, SQL Server and other databases into events.

Try it on your machine Read the event docs

Terminal

$ weikio events list finance/invoice-created --env production --since 1h
SEQ     STREAM   TIME                      FAMILY   SOURCE                       AGENT         BYTES   RESEND OF
48211   events   2026-09-16 13:02:11 UTC   ev       finance/erp-invoice-export   agent-fi-02   1204    -
48212   events   2026-09-16 13:03:11 UTC   ev       finance/erp-invoice-export   agent-fi-02   1187    -
48213   events   2026-09-16 13:04:40 UTC   ev       finance/invoice-files        agent-fi-02   2310    -

Publish and react

In this example, finance/erp-invoice-export publishes each invoice the ERP has accepted to the channel invoice-created in its last step, and finance/invoice-notify starts from that channel. The two integrations refer only to the channel and never to each other.

finance/channels/invoice-created.yaml

apiVersion: weik.io/v1
kind: event-channel
metadata: { name: invoice-created, project: finance }
spec:
  description: One event per invoice created in the ERP, JSON body

finance/erp-invoice-export/routes/export-invoices.camel.yaml

- route:
    id: export-invoices
    from:
      uri: "file:{{invoice-folder}}"
      parameters:
        antInclude: "*.json"
        move: .done
      steps:
        - to:
            uri: "{{erp-url}}/api/invoices"
            parameters:
              httpMethod: POST
        - to: micrometer:counter:invoices_processed
        - to: "kamelet:weikio-event-sink?channel=invoice-created"

finance/invoice-notify/routes/notify.camel.yaml

- route:
    id: invoice-notify
    from:
      uri: "kamelet:weikio-event-source?channel=invoice-created"
      steps:
        - log: "Invoice event received: ${body}"
        - to: "{{notify-url}}/api/messages"

Terminal

$ weikio deadletters list --env production
SEQ   TIME                      READER                   FROM                              DELIVERIES   REASON
812   2026-09-16 13:05:02 UTC   finance/invoice-notify   channel finance/invoice-created   3            HttpHostConnectException: Connect to https://notify.example.internal failed: Connection refused

The Events page of production filtered to channel events, with invoice-created events from erp-invoice-export, each with its invoice number and supplier, and the events budget of production — Events lists the newest events of each channel with their attributes, beside the events budget of the environment.

Sources, channels and subscriptions

An event source brings events into a channel named after it, from a queue, a bucket, a webhook, a folder or anything else a Camel source kamelet can consume. A subscription routes them on to another channel, with filters and steps that change them on the way. A channel that delivers to another system, such as Slack, S3 or Kafka, sends them out, and your own integrations read and publish in between.

How events are delivered

Delivery and retries

Publishing waits until Weik.io has stored the event. Each reader gets every event published from its first deploy on and acknowledges it when its route has finished it. A failed event comes back after the delays the reader sets.

Docs: Delivery and CloudEvents

Idempotent consumer

An event keeps its ID when it's delivered again or resent. Camel's idempotent consumer with #weikioIdempotent handles each event once across every copy of the integration.

Docs: Delivery and CloudEvents

Dead letters and resend

An event that a reader still fails after its last attempt goes to the dead letters, where you resend or discard it. You can also skip a reader to now, rewind it, or resend any stored event to every reader or to one.

Docs: Dead letters

CloudEvents 1.0

Every stored event carries its CloudEvents 1.0 attributes as ce- headers. A channel delivers in binary mode with those headers, or in structured mode as one application/cloudevents+json document.

Docs: Delivery and CloudEvents

Event headers

An event keeps the body your route published, unchanged. Beside it the platform stores the event's ID, the integration that published it, the agent that sent it and the trace context, so a reader's trace continues the publisher's trace.

Docs: Delivery and CloudEvents

Change tracking

Changes in PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, Db2 and every other database with a Debezium connector arrive in a channel as events. The offsets stay in a table in the source database.

Docs: Change tracking

The entity store

Integrations keep a record of what they have processed in the entity store. Every change to a record is published as an event, and earlier revisions of each record can be read back.

Docs: The entity store

Machines and devices

Machines publish their readings to an MQTT broker, and an event source brings the messages into your channels with CloudEvents attributes.

Docs: Event sources

The Dead letters page of devtest with invoice-created events that invoice-approvals failed on because the approval service couldn't be reached — Dead letters lists the events a reader couldn't handle after its last attempt, with the reason, and Resend sends one back to its reader.

Events track

Six videos cover channels, sources, subscriptions, delivery and dead letters, and three pattern videos show them in use.

Eventing 1 · 3:48 The channel: one integration publishes, another reacts

Eventing 2 · 3:26 An event source brings events in

Eventing 3 · 3:41 A subscription binds source to channel

Eventing 4 · 3:12 Delivery: give a channel a type

Eventing 5 · 3:21 On the way: filter and steps

Eventing 6 · 3:21 Dead letters

Patterns 1 · 3:45 Polling and change detection

Patterns 2 · 3:04 Sending data to several destinations

Patterns 4 · 3:47 React to database changes

See all event videos

Questions

Does a reader miss events while it's stopped?

No, it gets them when it starts again, as long as the environment still keeps them, and Weik.io raises a problem when a waiting event gets close to the age at which it's deleted.

How long are events kept?

Events are kept for 30 days per environment within a size budget, and a channel can also pass its events through without storing them.

What happens to an event a reader keeps failing?

After the last attempt the event goes to the dead letters, where you resend it to that reader or discard it.

Which databases does change tracking support?

Change tracking works with every database that has a Debezium connector, PostgreSQL, MySQL, SQL Server, Oracle, MongoDB and Db2 among them.

Is Weik.io open source?

Yes, Weik.io is open source under the Apache License 2.0 and runs on your own servers, in your cloud or in Weik.io Cloud.

Read the event docs

In the channel guide you declare invoice-created, publish into it from one integration and receive its events in another.

Read the event docs Try Weik.io