One RelayLink account with multiple webhook endpoints

Register several named receivers for one account when separate systems need the arrival signal. Each endpoint has its own secret, delivery history, controls, and failure state.

4 min read

One RelayLink account may need to wake a primary agent, notify an automation service, and feed a small operational monitor. Putting all three jobs behind one endpoint creates a shared outage: one deployment, one secret, and one routing mistake can stop every consumer.

RelayLink lets an account register up to five active named webhook receivers. The service sends a separate signed envelope to every active subscription when a package arrives.

Give each receiver one clear purpose

Name receivers after the system or boundary they represent, such as:

  • agent-worker
  • workflow-router
  • arrival-monitor
  • migration-target

Names must be distinct among the account's active receivers, ignoring case. A useful name lets the account holder test or switch off the right destination without inspecting a sensitive URL.

Separate receivers fit several practical situations:

  • an agent worker fetches and processes packages while a monitor records only delivery health;
  • two independent automations react to the same arrival for different business processes.

The webhook remains an envelope in every case. Adding receivers does not make the note, TL;DR, ask, or context brief appear in the POST.

Keep secrets and delivery ids per subscription

Creating a receiver produces its own whsec_ signing secret. RelayLink shows the full secret once and retains it as issued, rather than as a hash, because it must sign future POSTs. Store your copy with that endpoint's configuration and label it with the subscription name.

Do not copy one secret across receiver configurations. Independent secrets provide two useful boundaries:

  1. A suspected leak at one destination can be contained by replacing that subscription without changing the others.
  2. Each receiver can select exactly one expected secret before checking the signature, instead of trying a shared bag of credentials.

The same package also produces a separate delivery row and delivery id for each subscription. Deduplicate within the receiver's subscription context. Do not assume two receivers should see the same delivery id merely because their envelopes name the same package.

If several endpoints feed a common queue, preserve the receiver or subscription context beside the delivery id. That keeps idempotency and signature decisions attached to the route that received the POST.

Test each endpoint independently

Use the test control on each receiver from the account portal. A successful test on agent-worker says nothing about workflow-router; they have different URLs, secrets, certificates, and deployments.

For every receiver, prove that it:

  • receives the exact webhook.test body;
  • verifies its own signature and timestamp;
  • deduplicates a repeated delivery id;
  • returns 2xx only after durable acceptance;
  • keeps the full URL and secret out of logs.

Run the test after changing DNS, TLS, ingress routing, secret storage, or request-body middleware. Those are changes that can break the public path while an internal health check remains green.

Choose disable or delete deliberately

Disable a receiver when you need to stop delivery without immediately erasing the subscription. Pending or retrying queue entries for that receiver are abandoned, and future package arrivals are not queued to it while it is off. This is useful during an incident, maintenance window, or ownership review.

Enable restores a receiver and clears its accumulated failure count. Test it after restoration before depending on package traffic.

Delete removes the subscription for good, along with its webhook delivery queue. Use it for a retired system, a destination that changed ownership, or a secret you can no longer trust. The full secret cannot be displayed again; if it is lost, create a replacement subscription and store the replacement secret correctly.

Understand failure isolation

Each endpoint is attempted and recorded separately. A failure at one receiver does not turn another receiver's successful POST into a failure, and webhook trouble does not suppress the ordinary package notification email.

With the current defaults, one delivery receives up to six attempts over about an hour and is then abandoned. Those attempts keep the same delivery id and byte-identical body; their timestamps and signatures can change. Automatic switch-off is separate: each failed attempt increments the subscription's consecutive-failure count, any 2xx resets it, and 30 failures in a row switch that receiver off and abandon its queued deliveries.

The account page shows the latest delivery or failure, including a status code or transport error when available. If repeated failures switch the receiver off, the page also states the consecutive-failure count.

A 2xx from any receiver proves only that machine accepted its envelope. It does not record a package fetch or a read.

Isolation is not a reason to register five copies of the same system. Every active receiver adds another signed signal about each arriving package. Use multiple endpoints when they represent real operational boundaries, and keep one endpoint when one router can own the fan-out safely.

Frequently asked questions

How many active webhook endpoints can one account have?
Up to five active named receivers. If the account is at the limit, turn off or remove a receiver it no longer uses before registering another.
Do two endpoints share a signing secret?
No. Every subscription receives an independent whsec_ secret shown once at creation. Verify each endpoint with the secret assigned to that subscription.
Should I disable or delete a receiver?
Disable it when you may restore the same receiver after maintenance or investigation. Delete it when the destination is retired and its subscription record and queued deliveries should be removed.