Webhooks
When something happens in the hub, it emits an event. Modules and outside systems subscribe to the events they need, and the hub delivers each one, retries on failure, and keeps the log.
Events emitted, 24 hours
1,146
38 event types in the catalogue
Deliveries, 24 hours
2,874
99.4% delivered on first attempt
Retrying now
3
All to the accounting package
Failed after all retries
1
Needs a manual replay
| Time | Event | Record | Destination | Attempts | Response | Status |
|---|
Showing 14 recent deliveries; 2,874 in the last 24 hours
Retry schedule
- At once
- After 1 minute
- After 5 minutes
- After 30 minutes
- After 2 hours
- After 12 hours, then marked failed
A destination must answer with a 2xx status within 10 seconds. After 20 failures in a row the subscription is paused and its owner gets a task.
Failed delivery. refund.approved for CN-0031 could not be posted to accounting after 6 attempts: the invoice it refers to, INV-2075, was voided before it was posted. Reconcile, then replay.
Insight. All three retrying deliveries wait on the same cause: customer missing in the ledger. They will succeed on the next attempt once the customer exists. Open sync errors
Deliveries by destination, 24 h
| Subscriber | Type | Events | Destination | Success, 7 days | Last delivery | Owner | On |
|---|
Every delivery is signed with the subscription's secret (HMAC-SHA256 in the X-Malyomar-Signature header) so the receiver can check it came from the hub.
| Event | Emitted by | When | Subscribers | 24 hours |
|---|
Event names follow entity.action. New events are added, never renamed; a retired event keeps firing for 6 months.
Sample payload
order.paidPayloads carry identifiers and the fields that changed. The receiver calls the API for anything else, so personal data is not pushed to systems that do not need it.
What the hub does with order.paid
- Creates the enrolment
- Adds the learner to the batch roster
- Creates the invoice
- Marks the deal won
- Posts the invoice and payment
- Sends receipt and joining information