Krizaka
Documentation

Notifications

krizaka-notifications : e-mail, SMS et webhooks derrière un seul port, pilotés par les événements, gabarits par langue.

krizaka-notifications sends notifications according to the channel. Applications never talk to an SMTP server or an SMS provider: they publish an event, this service renders and delivers.

Channels

ChannelAdapterConfigurationAvailable when
EMAILSMTPMAIL_HOST, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD (defaults to a local Mailpit)always
SMSTwilio Messages APITWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, TWILIO_FROM_NUMBERall three are set
WEBHOOKHTTP POST of {template, subject, body}NOTIFICATIONS_WEBHOOK_ALLOWED_HOSTSthe allow-list is not empty

A request for a channel that is not available fails and is dead-lettered — never dropped silently. Templates live in templates/<template>/<locale>.txt (Subject: first line, {{variable}} placeholders, en fallback); point NOTIFICATIONS_TEMPLATES at a directory to brand them without a rebuild.

What triggers a notification

Routing keyWhat is sent
evt.user.registeredverification e-mail
evt.password.resetpassword-reset e-mail
evt.notification.requestedany NotificationRequest (channel, recipient, template, variables)

Every queue has its dead-letter queue, retries back off exponentially and deliveries are idempotent by messageId (messaging).

Request a notification

pom.xml
<dependency>
  <groupId>com.krizaka</groupId>
  <artifactId>krizaka-notifications-api</artifactId>
  <version>0.1.0</version>
</dependency>

Publish a NotificationRequest as JSON on the events exchange with the routing key evt.notification.requested and a messageId — a redelivery is then sent once. The request's JSON Schema ships in krizaka-notifications-api at events/evt.notification.requested.v1.json.

The full configuration and the run instructions are in the repository's README.

Sur cette page