Give your client the project, not a seat on your plan
A client portal your customer opens with a ten-character key: every report on their site, the stage each one is at, and a reply box. No account, and no seat.
Included on every plan
A named access per person, with its own key you revoke or regenerate
They see the project's progress: every ticket, or only the ones you mark
How it works
- 01
Add the person
A client access is created per person, in the panel or with the create_client_portal_access MCP tool. The server draws the key; nobody chooses it, and you are shown it once.
- 02
They open the project's page
Your project has its own portal address. They type a ten-character key, drawn from an alphabet with no O/0 and no I/1 because somebody reads it out loud, and it is exchanged for a session lasting 90 days.
- 03
They follow the work
Project progress leads the page: a count per stage and a bar across them. A bell carries what changed since they last looked: a stage moved, or the team replied.
A key you can take back
A client access is a row you own rather than a link that leaked. The key is kept as a scrypt hash and never rendered again after the once you are shown it; revoking one person ends their session without touching anybody else's, and regenerating hands them a new key while the old one stops working the same second. A reporter's link, by contrast, can only expire. When somebody leaves the client's team, that difference is the whole point.
They see progress, not your workings
What crosses is the stage, the title, the original report and the comments marked visible to the client. Priority, severity, assignee, labels, the console and network capture, the session replay and every internal note stay on your side, and that split is a predicate in the query rather than a filter in the interface. Even the vocabulary changes: the column your team calls WIP reads “In progress”, and QA reads “In QA, ready for you to check”.
Exact behaviour
- Access
- A named access per person: a ten-character key exchanged for a 90-day session, at the project's own portal address
- Shows
- The project's progress: every unarchived ticket, or only the ones you mark visible
- Key
- Ten characters from a 32-symbol alphabet with no O/0 and no I/1, kept as a scrypt hash, shown once
- Seats
- None. A client access is not a member and never counts against the seats on your plan
- Revocation
- Per person, at once; regenerating a key ends the sessions opened with the old one
- Privacy
- Priority, severity, assignee, logs, replay and internal comments never cross; screenshots and recordings are a per-project switch
- Branding
- The project's logo, accent and radius; “Powered by Notarus” hidden with whitelabel on Pro
- Language
- English, Spanish, Portuguese, French or German, set per project
- Plan
- Every plan
- MCP tool
- create_client_portal_access · list_client_portal_access · revoke_client_portal_access · send_client_portal_invitation
- MCP settings
- get_client_portal · set_client_portal · regenerate_client_portal_access_key · set_ticket_portal_visibility
Works with
Questions teams ask before installing
Does a client access use a seat?
No. The seat count on your plan counts members of your organisation, and a client access is a row on the project instead. Add as many client contacts as the work needs; none of them changes your bill.
What happens when somebody leaves the client's team?
Revoke their access and their session ends. Each person has their own key, so nobody else is interrupted and there is nothing to re-send to the rest of their team.
Can we show a client only some of the tickets?
Yes. The portal runs in one of two modes per project: every unarchived ticket, or only the ones marked visible. The mark is per ticket, from the board or with the set_ticket_portal_visibility MCP tool.
The thinking behind it
Stop forwarding screenshots to your client.
The client portal is included on the Free plan.