There are two customer links, not one
The ticket detail screen can produce two different links for a customer, and because they look identical in a chat window it is worth being precise about which one you just sent. One is a portal link, scoped to an email address. The other is a share link, scoped to a single ticket. They are backed by separate stores, they expire on different clocks, and only one of them survives being used.
The portal link is the one you want most of the time. It is issued against the requester email on the ticket and it opens that person view of their tickets, so a customer with three open issues sees three. It lasts thirty days by default and it can be used repeatedly, which is what makes it worth bookmarking.
The share link is narrower and shorter-lived. It grants access to the one ticket it was minted for, it lasts seven days, and it is single use: the moment it is redeemed it is marked used and will not open again. Send that one when somebody needs to see a specific thread once.
No requester email means no portal link
Portal links are scoped to an email address, so a ticket without a requester email cannot produce one. The screen says exactly that rather than issuing something broken, and the fix is to fill in the requester email on the ticket first.
This catches people out most often on tickets that arrived from a channel rather than from a form. A message that came in over SMS or Messenger has a phone number or a platform handle attached, not necessarily an address, so the portal button will refuse until somebody asks the customer for one. That is a reasonable place to ask for it anyway, because an email address is what lets you reach them when the channel goes quiet.
It also means the portal is organised around the address, not the person. Two addresses belonging to the same human are two portals. If your queue is full of near-duplicate requesters, the tidying described in our guide to keeping your contact list clean pays off here as well as in reporting.
What a second click does
Pressing the portal button again does not usually mint a new link. The issue path looks first for an active, unrevoked, unexpired token for the same address and returns that one if it finds it. So a customer who asks twice keeps the link they already have, and any bookmark they made still works.
The screen tells you which of the two happened, flagging the response as reused rather than freshly issued. That distinction matters when you are trying to work out why somebody is holding a link that expires sooner than you expected: they are holding the original, and the clock started when it was first issued rather than when you last pressed the button.
If you actually want a fresh link with a fresh thirty days, the existing one has to be revoked first — and revocation is an API operation rather than a button on the ticket screen, so it is worth wiring into whatever tooling your team already uses. Revocation is recorded rather than deleted, so a link that stops working leaves a trace of why.
What the link is made of
A portal token is thirty-two random bytes rendered as a short URL-safe string, generated from a cryptographic random source. A share token is thirty-two random bytes rendered as sixty-four hexadecimal characters. Neither is derived from the ticket number, the email address or anything else guessable, and the share token is checked against its exact expected shape before the database is touched at all, which turns malformed input into an immediate rejection.
That entropy is doing real work, because the link is the credential. Anyone holding it can open what it points at. There is no password step behind it, and there is no second factor. Treat one the way you would treat a password reset link: fine to send to the address it belongs to, not fine to paste into a shared channel or a group chat.
Validation distinguishes between a token that does not exist, one that has expired and one that was revoked, so the page a customer lands on can say something more useful than access denied. When a customer reports a dead link, the specific message they saw tells you which of the three happened.
Delivering the link is your job, not the products
Issuing a link does not send it anywhere. The screen hands the URL back to you so you can paste it into a reply, and a ticket.portal_token_issued event is raised for whatever automation you have built on the webhook feed. If you have not built that automation, the only copy of the link is the one on your screen.
That is a sensible default — the product does not decide which of a customer addresses to mail — but it makes the delivery step easy to forget. Decide up front whether links go out by hand in a reply, or automatically via an email template driven by the event, and write the choice into your process. Sending it into the same channel the customer contacted you on is usually right, since it is the address they are watching.
If you route the event into your own mail flow, our note on sending events to your own systems covers the shape of that feed and the retry behaviour behind it.
When to send which
Send a portal link when the relationship is ongoing: a customer with several tickets, an account manager who keeps checking in, anyone you expect to come back. Thirty days and repeat use is exactly right for that, and the bookmark stops them opening a new ticket to ask about an old one.
Send a share link when the need is specific and finite: proof of what was agreed on one thread, a record somebody wants to forward to their finance team once, an escalation where a named person needs to read a single conversation. Seven days and one use limits the blast radius if the message is forwarded further than you intended.
What you should not do is use either as a substitute for an account. A link is a convenience, not an identity check, and it should never be the gate in front of anything you would not be comfortable emailing to that address unprompted. Where identity genuinely matters, the practices in our guide to verifying customer identity apply here unchanged.
The hygiene that keeps this safe
Set an internal rule about where links may be pasted. The common failure is not an attack; it is a support agent dropping a portal link into a shared team channel so a colleague can look, and that channel being readable by forty people and searchable forever.
Watch the address you are sending to, particularly on tickets created from a channel or imported in bulk, where the requester email may have been filled in by somebody other than the requester. A portal link sent to a mistyped address is a disclosure, and the thirty-day lifetime means it stays one for a month unless somebody revokes it.
Revoke on offboarding. When a customer relationship ends, or when somebody at the customer end leaves and you are told about it, revoking the outstanding token closes the loop properly. Because revocation runs through the API rather than the ticket screen, make it a line in the offboarding checklist you already keep instead of something an agent is expected to remember. The same instinct applies internally, which our guide to offboarding agents goes through in more detail.
What to tell the customer when you send it
One sentence is enough, and it should carry three facts: what the link opens, how long it lasts, and that it should not be forwarded. Customers do not know that one of your two link types dies after a single use, and a person who opens a share link on their phone, then forwards it to a colleague who finds it dead, will report that as a bug in your product.
It also helps to say what they can do once they are in. A portal shows their tickets and lets them reply; it is not a full account, it will not show them anybody else tickets, and it does not replace contacting you. Setting that expectation in the sentence that carries the link saves the follow-up question.
If the customer loses it, reissue rather than troubleshoot. A portal link that is still active comes back unchanged anyway, so pressing the button is the fastest diagnostic you have — and if it comes back flagged as newly issued, you have learned that the old one had expired or been revoked, which is usually the answer to why it stopped working. The whole flow lives alongside the rest of the queue in the shared inbox, so the link is never more than a click from the conversation it belongs to.