Integration Event
What It Is
An integration event represents information moving across the boundary between Rhythm and a provider. A provider can send a notification about an account operation. Rhythm retains that incoming message, verifies it through the adapter and turns its meaning into a typed event for consuming applications. In the opposite direction, an application change can become a projected delivery for a subscribed integration.
These forms share a need for identity, routing and visible processing results, but they have different origins. The received provider message preserves what arrived. The internal event expresses a meaning an application can consume. The outgoing delivery is one subscription’s copy of a Rhythm change. Keeping those distinctions helps Product investigate where a missing update stopped rather than describe every item simply as a webhook.
What It Is Not
A notification is information about something that happened, rather than an instruction to repeat a provider operation. A capability call has its own request and settlement. An application business event may trigger workflow automation, but its publication and host processing remain separate from the provider notification record. A subscription likewise represents a saved interest rather than one individual delivery.
How It Is Used
Administrators configure endpoints and subscriptions, inspect messages and deliveries, and request replay when a processing problem is corrected. Readers inspect those records without receiving signing secrets or initiating recovery. Application consumers interpret routed events for their own business records and report whether they handled, ignored or need another attempt.
Useful investigation follows the message from receipt through interpretation and routing. A retained message gives replay something concrete to process. A dead delivery tells staff automatic work ended, while an unclaimed internal event identifies a missing consumer. Retry can deliver an event again, so consumers need to recognize its identity rather than treat every arrival as a new business fact.
Its Facets
Endpoint. A public address belongs to a connection and notification kind. Its secret supports verification, with a separate setup and rotation lifecycle.
Received message. Stored body and selected headers preserve the incoming material. Verification, duplicate handling and processing determine whether it produces events.
Typed event and consumer. Event contracts describe interpreted information. Consumers register interests, and completion routing additionally respects the application that made the call.
Subscription. The installation’s accepted event interests and optional conditions govern which Rhythm changes are eligible to leave the application.
Delivery. Each projected change retains its own progress. Push acknowledgement, pull cursor movement, repeated failure and operator replay give different ways to explain that progress.
How It Relates
Connection removal disables notification endpoints. Installation removal deletes its subscriptions. Capability settlement produces completion events, and matching provider references can relate a notification to the Rhythm record responsible for the provider object. Extension business-event declarations are neighbouring shared information, but external delivery belongs to the integration path rather than a second customer subscription system.
What It Could Become
The product should decide the acceptance boundary for this machinery through the proposed webhook and event milestone. Retry semantics need a clear consumer contract, including the possibility of another delivery to a consumer that already handled an earlier attempt. Product also needs to distinguish pull delivery from the unbuilt synchronization-profile experience. Working service code and retained messages establish implementation evidence, while recovery promises and additional delivery channels still require product decisions.