Make can receive a RelayLink webhook and expose the two inputs needed for signature calculation: the original JSON text and custom request headers. That does not by itself make the scenario a complete security boundary.
Make's Custom webhook documentation describes JSON pass-through, which sends the original JSON to subsequent modules as a text string instead of splitting it into mapped fields. The same page documents Get request headers, which exposes incoming headers. Make also provides HMAC-SHA256 hash functions.
The unresolved part is comparison. The documented scenario filter compares values normally; Make does not document that comparison as constant-time. For a signing secret protecting a public endpoint, do not quietly treat ordinary equality as equivalent.
What a direct scenario can observe
A Custom webhook can receive RelayLink's POST. Enable JSON pass-through and request headers before taking a test sample. Without pass-through, Make parses JSON into a bundle. Recreating text from that bundle can alter spacing, property order, escaping, or date representation and invalidate an exact-body signature.
RelayLink signs:
{X-RelayLink-Timestamp}.{exact JSON body string}
The key is the one-time whsec_ secret. HMAC-SHA256 produces 32 bytes, rendered as lowercase hexadecimal after sha256=. The other two headers are X-RelayLink-Event and X-RelayLink-Delivery.
Make's SHA-256 function can take an HMAC key and output hexadecimal. That allows an isolated diagnostic scenario to test whether the pass-through text produces the expected digest, but that scenario must not trigger an agent or any external action. It does not establish the required constant-time comparison, and the secret would need to be available to the mapping that calculates the HMAC. Do not paste it into a visible scenario field merely to complete the route.
The Custom webhook's optional API-key authentication also does not solve the direct connection. Make expects its own X-Make-Apikey header, while RelayLink's subscription contract does not let an account add arbitrary outbound authentication headers.
Make's response timing changes reliability
By default, Make returns an accepted response as the Custom webhook executes. A Webhook Response module can customize the response later, but Make documents that if no response is available before its response timeout, it sends a 200 accepted response.
RelayLink's delivery attempt has a much shorter request budget. An AI step, several remote actions, or a delayed scenario response therefore belongs after acceptance, not inside the callback. More importantly, a platform-generated 200 can arrive before your scenario has authenticated or durably claimed the delivery.
That means a direct Make URL can be useful for inspecting test events, but the current official documentation does not establish the exact production guarantee RelayLink needs: reject unauthenticated requests, and return 2xx only after verified work is durably accepted.
Use a verifier bridge as the receiver
Put a narrow service before Make:
RelayLink -> verifier and idempotency store -> authenticated Make webhook
The verifier keeps the whsec_ secret in its platform secret store. It reads the HTTP body as bytes before parsing, computes HMAC-SHA256 over the timestamp prefix and those bytes, and compares the supplied 32-byte MAC with a constant-time primitive. It then applies your freshness policy and confirms that header event and delivery id equal their body fields.
In one durable operation, insert X-RelayLink-Delivery as a unique receipt and enqueue forwarding. Only then return 2xx. RelayLink retries use the same delivery id and byte-identical body, so an existing receipt with the same digest should succeed without adding a second scenario run.
The bridge forwards normalized JSON to Make and can supply Make's own API-key header. Keep that bridge credential separate from the RelayLink signing secret. The scenario no longer needs the whsec_ value or the original signature. Do not log the signing secret, signature, raw body, or a full token-bearing webhook URL.
Let Make orchestrate after authentication
For package.received, the forwarded data remains a JSON envelope: package and thread ids, sender, topic, time, reply status, and mcp_url. The message, briefing, and files are absent. A later service must authenticate independently to mcp_url and call get_package.
Do not make a sender name or topic into a Make agent instruction. Both are third-party strings. Verification proves who signed the envelope; it does not turn those strings into trusted commands.
Accepting the webhook or starting a scenario does not mark the package read. Only the later authenticated get_package call records that the recipient's assistant pulled it.
Create the bridge first, register its public HTTPS URL from the RelayLink account portal, and store the secret immediately. Use webhook.test to compare a correct body with one whose whitespace changed. Then send the same valid delivery twice and confirm Make starts only one scenario. This proves the bridge owns authentication and deduplication while Make owns downstream automation.