Secure signal relay
Send Signals Between Applications Without Keeping Them Connected
HeartbeatHook stores small authenticated signals until the receiving application retrieves them through its own polling flow.
A small mailbox between applications
The current Tier 1 flow is:
Application A --signed signal--> HeartbeatHook --pending mailbox--> Application B --ACK--> HeartbeatHook
The receiver does not need to accept an inbound request from the sender. It polls its authenticated signal flow, processes the payload in its own environment, and acknowledges the signal after its business action succeeds.
Useful signal types
- configuration refresh;
- synchronization trigger;
- work-available notification;
- state refresh;
- cache invalidation;
- lightweight coordination between private applications.
Current delivery semantics
Signals are stored as pending records and returned by the authenticated target read flow until ACK. Signal creation uses a stable idempotency key, so a timeout can be retried without creating a second signal for the same logical request. ACK is also idempotent. These properties make the flow retry-safe, but they do not provide exactly-once execution: the receiving application must make its own business action safe to repeat.
What this is not
HeartbeatHook is not a Kafka replacement, file-transfer service, large-payload transport or exactly-once execution engine. It is a focused HTTP contract for small application signals, authenticated polling and explicit acknowledgement.