Polling Relay

Receiver-controlled retrieval

Polling Relay describes a communication model in which the receiving application opens the connection and retrieves pending work when it is ready. This is useful for private applications, intermittent receivers, shared hosting and networks where inbound routing is difficult or undesirable.

How the model works

1. A sender creates an authenticated signal in the relay.
2. The receiver polls its authorized pending-signal flow.
3. The receiver processes the business action in its own environment.
4. The receiver acknowledges the signal after successful processing.

Current Tier 1 provides the authenticated pending read and ACK pieces. A standalone product registry, delivery policy and lease model are not yet implemented, so this page describes the product boundary around the current protocol rather than claiming a separate live SKU.

Advantages

• no public inbound webhook endpoint is required;
• the receiver chooses when to connect;
• intermittent availability is a normal part of the model;
• the protocol is explicit about read and ACK.

Limitations

Polling introduces latency and a scheduling responsibility. It is not universally better than a webhook, and it is not a high-volume streaming transport. The receiver must bound retries, preserve idempotency and avoid acknowledging before the business action succeeds.

Polling Relay versus Signal Relay

Signal Relay names the durable authenticated signal contract. Polling Relay names the receiver-controlled retrieval model used when inbound delivery is not a good fit. They are related, but should not be collapsed into one generic message-broker claim.

Compare polling with webhooks →