How senders work

Senders are fire-and-forget output adapters that sit alongside the channel and provider subsystems. Any channel or provider calls senders.send(id, configName, message) and the sender subsystem takes care of delivery.

Each sender can hold multiple named configurations, so a single email-smtp sender can deliver to several different inboxes simultaneously, each identified by a config name. Senders are installed and configured from the Manage Senders dialog in the Kwirth UI without writing any code.

Built-in senders

Leaf senders — deliver to an external destination

Routing senders — intercept, filter, and dispatch

The dispatcher pattern

Because senders receive the full ISenderAccess facade at startup, a sender can delegate to other senders. This is how tee, regex, composite, timed, and ratelimit work: they each intercept a message and decide which downstream sender (if any) should receive it.

You can chain them: a timed sender can forward to a regex sender, which can forward to a tee sender, which fans out to email-smtp and file.

Managing senders from the UI

Open the menu drawer and choose Manage Senders (requires cluster-scope access key). From there you can:

• View all installed senders with their version, description, and active config count
• Add, edit, and delete named configurations per sender
• Install new senders from a URL or a local .tgz upload
• Export and import configs as JSON — per-sender or all senders at once

Senders with a custom UI (composite, timed) open a dedicated editor instead of the generic config form when you expand their card.

Build your own sender

import { ISender, ISenderAccess, ISenderConfig, ISenderFieldDef, ISenderMessage }
    from '@kwirthmagnify/kwirth-common-back'

export class SlackSender implements ISender {
    readonly id = 'slack'
    private configs = new Map<string, { name: string; webhookUrl: string }>()

    getConfigSchema(): ISenderFieldDef[] {
        return [
            { name: 'name',       label: 'Name',        required: true },
            { name: 'webhookUrl', label: 'Webhook URL',  required: true },
        ]
    }

    async send(configName: string, message: ISenderMessage): Promise {
        const cfg = this.configs.get(configName)
        if (!cfg) throw new Error(`config '${configName}' not found`)
        await fetch(cfg.webhookUrl, {
            method: 'POST',
            body: JSON.stringify({ text: message.body }),
            headers: { 'Content-Type': 'application/json' }
        })
    }

    addConfig(c: ISenderConfig)  { this.configs.set(c.name, c as any) }
    removeConfig(n: string)      { this.configs.delete(n) }
    hasConfig(n: string)         { return this.configs.has(n) }
    getConfigNames()             { return [...this.configs.keys()] }
    async startSender(_: ISenderAccess): Promise {}
    async stopSender(): Promise {}
}

export default SlackSender

Webhooks

Inbound HTTP integration — the Integration extension family that lets external systems call into Kwirth. Where Senders push data out, webhooks bring data in.

What a webhook is

A webhook is an installable extension that exposes an HTTP endpoint inside Kwirth. An external service (GitHub, an Alertmanager, a CI job, a business app…) POSTs a payload to that endpoint, the webhook parses it, and routes it to a target channel or plugin — so the rest of Kwirth can observe and react to it in real time.

How it works

• Install a webhook extension and create one or more named configurations.
• Each config gets a unique Webhook URL that carries a secret token — you paste it into the external service.
• Every config picks a target: one of your installed channels/plugins that will receive the payload.
• Fields are rendered from the webhook's own config schema, so every option is typed — no guesswork.

Security

The inbound URL embeds a secret token, so only callers holding that URL can post — and you can rotate the token at any time to revoke a leaked URL. Inbound endpoints are part of Kwirth's access-key model; treat the URL as a credential.

Managing webhooks

Open ☰ → Manage extensions → Webhooks. Like every family, you can install from the catalog, from a URL, or by uploading a .tgz; versions are supported. Per webhook you manage its named configs, view/rotate each config's URL + token, choose the target, and export/import configs as JSON.