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.