Concepts
These are the terms used throughout the docs, the API and the dashboard. Where the dashboard uses a different name, it is listed in the last column.
The two directions
Section titled “The two directions”| Term | What it is | In the dashboard |
|---|---|---|
| Outgoing | Your event travels out of Railhook to endpoints your customers registered. Railhook is the sender and signs what it sends. | Outgoing |
| Incoming | A third-party provider’s webhook travels into Railhook and on to destinations you chose. Railhook is the receiver and verifies what it receives. | Incoming |
Outgoing
Section titled “Outgoing”| Term | What it is | In the dashboard |
|---|---|---|
| Event | Something your system says happened, with a type (such as order.completed) and a payload. It exists whether or not anyone is listening. |
Events |
| Endpoint | A URL that is willing to receive events, together with the secret its signatures are computed from. | Endpoints |
| Subscription | A standing statement that one endpoint wants events of a given type. | Subscriptions |
| Connection | One endpoint together with the subscriptions that point at it: the unit you configure, test and turn off. | Connections |
| Delivery | The obligation to get one event to one endpoint, held until it succeeds or is abandoned. One event fans out into one delivery per matching subscription. | Deliveries |
| Sequence number | An endpoint-scoped position on a delivery, used when ordering is on so deliveries to the same endpoint arrive in order. | — |
Incoming
Section titled “Incoming”| Term | What it is | In the dashboard |
|---|---|---|
| Source | A provider you have connected, together with what Railhook needs to prove a webhook came from it. | Sources |
| Incoming event | One webhook received from a source, kept exactly as it arrived. | Received |
| Destination | A URL you chose to receive incoming events, together with how to authenticate to it. | On each source |
| Forward | The obligation to get one incoming event to one destination. The incoming counterpart of a delivery. | — |
Attempts and recovery
Section titled “Attempts and recovery”Both directions share these.
| Term | What it is | In the dashboard |
|---|---|---|
| Attempt | One try at a delivery or a forward: one HTTP request and what it resolved to. | Attempts, on each delivery |
| Retry ladder | How long to wait before each further attempt, and how many attempts there are before giving up. Outgoing: 7 attempts, waiting 1m, 5m, 15m, 1h, 6h, then 24h. Incoming: 5 attempts, up to 6h. | — |
| DLQ | Where a delivery or forward lands once its retry ladder is used up, kept for a person to decide about. | Failed Messages (outgoing), Failed Forwards (incoming) |
| Replay | Building fresh deliveries from events already stored. A retry is the next attempt on the same delivery; a replay is a new delivery. | Time Machine |
| Tunnel | A local port on your machine made reachable at a public URL for as long as the CLI stays connected. | Tunnels |
Tenancy
Section titled “Tenancy”| Term | What it is | In the dashboard |
|---|---|---|
| Organization | The tenant. Everything you own belongs to exactly one. | Organization |
| Project | A division of an organization’s work. Endpoints, sources and API keys belong to a project. | Project |
Next steps
Section titled “Next steps”QuickstartPut the terms to work: send an event and watch it delivered.
Retries and failed messagesThe outgoing retry ladder in detail.
ReplayWhen to retry and when to replay.