SR SignalRelay
Menu
Sign in Start trial

SignalRelay product documentation

Connect an intermittent Agent to incoming work without running an always-on listener. This guide explains the model, first route, and supported access paths.

Core model

A Relay accepts authenticated input and routes it to one Agent. A Signal is the durable work envelope. An Agent creates a time-bound Claim, processes the Signal, and records an outcome.

Relay
Verifies input and fixes Agent ownership before work starts.
Signal
Stores a CloudEvents-compatible envelope and safe delivery metadata.
Agent
Pulls Available Signals through an Agent token or connected MCP client.
Claim
Records a lease and a final Completed, Deferred, or Failed outcome.

Your first complete route

  1. Create an account and verify its email.
  2. Create one Agent and save its one-time token in a secret store.
  3. Create one Relay, assign the Agent, and save the one-time Relay secret.
  4. Configure the producer and send one signed test delivery.
  5. Confirm that the Signal is Available.
  6. Let the Agent claim it, do the work, and complete the Claim.
Choose a plan

Supported ingress

SignalRelay has three canonical Relay endpoints:

POST /api/relays/:relay_id/github
POST /api/relays/:relay_id/slack
POST /api/relays/:relay_id/signals

GitHub and Slack Relays verify the provider signature from the original request body. Native Signal intake accepts a Jido.Signal-compatible map. Each Relay uses an encrypted, scoped secret and routes to one Agent.

Send native input as JSON. Put the one-time Relay secret in the x-signalrelay-relay-secret header. Keep that secret in a secret store and do not put it in the URL. 

curl -X POST \
  -H "content-type: application/json" \
  -H "x-signalrelay-relay-secret: $SIGNALRELAY_RELAY_SECRET" \
  --data-binary @signal.json \
  https://signalrelay.dev/api/relays/$RELAY_ID/signals

Agent access

Simple clients use the HTTP Claim API. Connected Agents can use the stateless Streamable HTTP MCP endpoint. Both paths use the same entitlement and lifecycle rules. 

POST /api/agents/signals/claim
POST /api/agents/claims/:claim_id/complete
POST /api/agents/claims/:claim_id/defer
POST /api/agents/claims/:claim_id/fail

POST /mcp

Agent API requests use Authorization: Bearer <agent-token>. MCP clients use a short-lived connected-client token. They do not use Agent tokens or Relay secrets.

Lifecycle

Accepted input creates an Available Signal. A Claim changes it to Claimed until the Agent completes, defers, or fails the Claim. A deferred Claim returns the Signal to Available. Leases prevent one Signal from being processed by two Agents at the same time.

Plan retention is 7 days for Solo, 30 days for Builder, and 90 days for Studio. An unpaid collection-only account keeps seven days of Signals and cannot start new Claims. Active Claims can finish.

Security rules

  • Store Agent tokens and Relay secrets in a password manager or secret store.
  • Do not put a secret in a URL, source file, screenshot, ticket, or log.
  • Rotate a credential after accidental exposure.
  • Use the exact raw request body when a provider signature requires it.
  • Use a separate Relay for each trust boundary and target Agent.

If a delivery or Claim fails, use the visible reason in the dashboard before you rotate a credential. Contact Support when the recovery step is not clear.