Event

An event records one change to one object. The same event can be read from /events and is what a webhook delivers.

The object

idstringAlways

An evt_ id. A webhook delivery repeats it in the Corgi-Event-Id header.

typestringAlways

What happened, such as payments.book_transfer.completed.

sourcestringAlways

The service that published it: payments, ledger, accounts and so on.

created_atstring · date-timeAlways

When the event was recorded.

dataobjectAlways

The payload the service published. For payments.book_transfer.completed it is the book transfer. For ledger.journal.posted it is the journal with its entries.

How types are named

A type reads <service>.<object>.<change>. For an object with a status, the last part is the status it moved to: payments.wire.settled, payments.check_deposit.returned, accounts.account.frozen. Objects that belong to a larger area add a level, as in ledger.nostro.account.opened.

The list of types is a catalogue in the code. A service can publish only a type that is in it, and the webhook side subscribes to exactly those types.

What is left out

Events from the customers and identity services are stored without personal fields: email, phone, date_of_birth, formation_date, address and the tax id fields are removed from data. Read the customer by id when you need them.

Reading and receiving

GET /events lists events newest first and takes a type filter, which matches the whole type and not a prefix. GET /events/{id} reads one.

Every type in the catalogue also reaches webhooks. When an event is recorded, a delivery is queued for each enabled endpoint whose event_types match it, and the body of the delivery is this object as JSON. A delivery can repeat, so treat the event id as the key for deduplication. Events and webhooks covers subscribing, signatures and retries.

Every field is listed in the Event object.