Something is wrong — a connector that will not connect, a package that never arrived, a question the docs do not answer. Start at /support. /help and /contact redirect there. The footer on every marketing page links it. Signed in, the same form is one tap from every account page.
hello@relaylink.ai stays on the legal pages and in the acknowledgement, because somebody whose problem is that RelayLink is not working needs a path that does not go through RelayLink.
Three ways in
The public form. No account required. No cookie either — an anonymous marketing page that set a cookie on every visitor would stop being cacheable. What bounds it: a honeypot field, a per-IP rate limit, and a per-address daily cap. The address you type is how we write back, not proof that the account is yours. An anonymous request carries no account facts, whatever address is typed.
Signed in at /account/support. The session already knows who you are.
From your assistant. open_support_request, support_status and reply_to_support are three of the thirty-eight tools. A support request is written to us, is not a package, and needs your own word. There is no tool for the assistant to answer as RelayLink: an answer under the company's name should cost a person typing it.
The reference is not a key
You will see a short reference like RL-7Q4M2X in mail, in a link, and on a page. It is so you can find the thread. It authorises nothing. Asking for a request that is not yours returns the same answer as asking for one that does not exist.
What lets you add to the thread by email is the Reply-To address on the mail we send you. That token appears only there. A matching signature on inbound mail proves the message reached us; it does not prove who typed it. Forwarding and aliases are ordinary, so a mismatched From is kept and flagged, not thrown away, and never treated as "the account holder said this."
Our reply always goes to the address stored on the request, never to an inbound From. Nothing arriving by email may authorise account recovery, an ownership change, a key action, or the disclosure of any private account fact.
What we keep, and what we do not
If the browser sends diagnostics, the server keeps a small allowlisted set — not a dump, and not identifiers from paths like /account/packages/{id}. The acknowledgement you receive echoes none of that.
You get the reference and a way to add more: reply to the mail, open the thread in your account, or tell your assistant to reply. If mail to you cannot be delivered, the desk sees that. "The provider took it" is not the same as "they got it."
For connector failures, troubleshooting MCP connection problems often settles it before a ticket. For everything else, open a request or ask your assistant once you are connected.