Skip to main content

​
Event catalogue

The event types currently published, the prefix each one’s data.id carries, and the payload fields the producing service sends alongside it. Every event also carries data.id, and data.customerId when the event belongs to a customer.
Further event families exist that are not broken out above. Money arriving also emits deposit.created and deposit.failed; movements also emit transaction.initiated, transaction.completed, transaction.failed and transaction.refunded. Their payload fields are not yet captured here, so subscribe with a glob — deposit.*, transaction.* — and read data defensively rather than assuming the columns above are the whole set.
Wallet events are best-effort. Both are emitted after the work has already succeeded, so if the emit fails the wallet still exists, or is still deleted — the API response is the authority, not the event. There is no wallet.updated: renaming a wallet emits nothing. See the Wallets guide.
data.status on an account event is Endl’s internal state name, not the value the Accounts API returns — activated where Get account says ACTIVE. On account.updated it can also be the pre-change value, because the event fires when your request is accepted rather than when it lands. Treat an account event as “something changed, go look”, and read the account for the real state.
The Accounts service documents exactly two account events — account.opened and account.updated. iban.assigned also carries an acct_ prefix and is listed above, so subscribe to and handle all three rather than assuming two. A queued open — one where Open account returned no id — emits nothing, so waiting on account.opened for it will hang forever; poll List accounts instead. Status changes Endl makes on its own, and funding instructions appearing later, also emit nothing. See the Accounts guide.
The prefix on data.id is the only thing that says what an event is about — txn_, acct_, cus_. There is no separate type field to read. Switch on the prefix, or on eventCategory.
Endl manages this catalogue and may add event types over time. Handle an unrecognised eventType gracefully rather than rejecting it, or a new event type becomes an outage in your receiver. Subscribe with globs — payout.* — to pick up related types automatically. Which types are enabled is governed per environment, so sandbox and production can differ.

​
Card events

Card events use the same subscription, envelope and signature, with the object in data. The card API is not final yet. See Card webhook events.

​
Payload schema versions

Versions are calendar-versioned — YYYY-MM.N, where the month is the month the schema last changed and N is an increment within that month. 2026-09.1 is the current and only shipped version. A schema that has not moved since March keeps saying 2026-03.1 in September; the version never advances just because time passed, because it sits inside the signed body and a pointless bump would break every verifier for nothing. Read version from the envelope rather than hard-coding a literal, and treat an unfamiliar version string as informational rather than a reason to reject the event. The string is fixed when you create the subscription and cannot be changed afterwards. Subscribing is when schemaVersion is checked. Matching is exact and nothing is trimmed.
The format refusal and the support refusal are deliberately distinct, because the fixes differ: the first says you spelled it wrong, the second says you named a real version Endl does not ship. The strictness is on purpose — the version sits inside the signed body, so two spellings of one version would be two different sets of signed bytes.

​
Delivery modes

​
Subscription status

Pausing frees a subscription slot but does not free the URL. A PAUSED subscription still holds its target, because it is holding a backlog that would be double-delivered if a second subscription took the same URL — so re-registering that target is a 409. A DELETED subscription does not collide: re-registering its URL succeeds and creates a new subscription, with a new id and a new signing secret.

​
Delivery status

A delivery is one event going to one subscription. Two matching subscriptions produce two deliveries of the same event, each with its own status, attempt count and failure — which is what makes “why didn’t my second endpoint receive this?” answerable.

​
Error classes

lastErrorClass, and each attempt’s errorClass, is one of:

​
Limits and delivery behaviour

Answer any 2xx as fast as you can and do the work afterwards — the read timeout is 10 seconds, and a slow receiver turns into a TIMEOUT retry storm. Redirects are not followed, so register the final URL. Verify the signature before doing anything with the body, and dedup on eventId: at-least-once delivery means the same event can legitimately arrive twice.