Webhooks and events

Coming soon. Webhook delivery is not live yet. This page summarizes the principles already decided; details will be added when delivery is ready.

What is decided

• Webhooks are sent through the internal reliable message queue (outbox).

• Every request carries an HMAC-SHA256 signature and a timestamp; the receiver is expected to verify both.

• Failed deliveries are retried; events that ultimately cannot be delivered go to a dead-letter queue.

• Target addresses pass outbound-request (SSRF) protection; not every address may be callable.

• The event name and its version are part of the external contract. If an event's schema changes, a new version of the event is published; the old version is supported per the versioning policy.

• Event names and payload fields will be in English.

• The event envelope carries the event type, its version, the type and identifier of the related record, the legal entity where applicable, the initiating subject (user or client) and a correlation identifier. Events of the same record are processed in order.

• The event of a change you initiated yourself may not be sent back to you (this loop-prevention rule applies to channel adapters).

• The same event may be delivered more than once; your receiver should ignore duplicates by event identifier (idempotent handling).

Not yet known

Bulk data (already planned)

Besides webhooks, Excel/CSV import and export templates are planned. Column keys are fixed, language-independent and in English; money and quantities are fixed-scale strings, and dates are ISO 8601.