Share Sherpa conversations securely with teammates

Sherpa lets you share any conversation you own with specific teammates. Sharing generates a one-time invite URL. Recipients who click the link see a read-only copy of the conversation, including all answer cards and citations, but cannot send new messages or alter the content. Sharing is invite-only — only existing Sherpa users listed as invitees can open the link. When you share a conversation, Sherpa creates a share record that binds the conversation to a list of invited user IDs and an expiry timestamp. The share is backed by a token-protected URL. Recipients do not get a copy of the conversation data; they read it directly from the original — which means that if you revoke the share, they immediately lose access, even if they still have the URL. Shared conversations appear in each recipient’s conversation list under a separate “共有された会話” (Shared conversations) section and are permanently read-only.

Open the conversation you want to share

Select the conversation in the left pane. Only conversations you created can be shared — received shares cannot be re-shared.

Click the Share button

The Share button is in the conversation header. If the button is disabled, the conversation contains personal workspace references and must be sanitized before sharing — see the warning below.

Enter the invitee user IDs

Type the Sherpa username(s) of the people you want to invite. Separate multiple usernames with spaces or commas. All recipients must be existing Sherpa users; unknown user IDs are rejected.

Set an expiry date

Choose when the share should expire. After the expiry date, the link becomes invalid and recipients can no longer open the conversation. You can set any future date.

Generate and copy the share link

Click the button to generate the share. The URL is displayed immediately.

The share URL is displayed only once. Copy it before closing the dialog. If you lose the URL, you must revoke the existing share and create a new one — there is no way to retrieve the original token.

Create share
Revoke share
Accept share (recipient)

POST /conversations/{cid}/shares
Content-Type: application/json

{
  "invitee_user_ids": ["alice", "bob"],
  "expires_at": "2025-12-31T23:59:59Z",
  "sanitize": false
}

A successful response includes the share ID and the one-time URL:

{
  "ok": true,
  "share_id": 42,
  "url": "/share/conversations/<token>"
}

Recipients open the share URL in their browser while logged in to Sherpa:

GET /share/conversations/<token>

Sherpa verifies that the token is valid, the share has not expired, and the current user is on the invite list. On success, the conversation is added to the recipient’s “shared conversations” list and they are redirected to it.

Expiry

The share becomes invalid as soon as expires_at is reached. Sherpa checks the expiry on every access attempt — there is no grace period. Recipients who open the URL after expiry see an access-denied message. Plan your expiry dates accordingly; you can always create a new share with a later date.

Conversations that include personal workspace file references (i.e., answers that searched your personal files) carry a contains_personal_workspace flag and cannot be shared through the standard flow. The Share button is disabled in the UI, and the API returns HTTP 409.You can share these conversations using sanitize: true in the API. A sanitized share creates a frozen snapshot of the conversation where all personal turns — both the question and the answer — are replaced with redacted placeholders. Non-personal turns are rebuilt from an allowlist of safe fields (headline, summary, scope, shared-KB citations). The snapshot has contains_personal_workspace = false so it passes the share guard.Important limitation: Sanitization removes turns that Sherpa identified as containing personal file references. It does not automatically redact personal information that you typed by hand into the message box (names, account numbers, internal codes, etc.). You are responsible for reviewing the sanitized content before sharing.

To create a sanitized share:

POST /conversations/{cid}/shares
Content-Type: application/json

{
  "invitee_user_ids": ["alice"],
  "expires_at": "2025-12-31T23:59:59Z",
  "sanitize": true
}

Passing sanitize: true always creates a snapshot, even if the conversation does not have the personal flag set — this protects against in-flight races where the flag may not yet be written. You can revoke any share you created at any time from the UI (conversation header → Share → Revoke) or via the API (POST /conversation-shares/{share_id}/revoke). Revocation is immediate and permanent. Recipients who have already accepted the share lose access to the conversation from that moment.

Audit log

All share-related events are recorded in Sherpa’s audit log:

Event	Recorded when
`share.created`	A share link is successfully issued
`share.sanitized_snapshot`	A sanitized snapshot share is created
`share.accepted`	A recipient successfully opens a share link
`share.denied`	A share link attempt is rejected (invalid token, expired, not invited, revoked)
`share.revoked`	The owner revokes a share

Administrators can review the audit log at GET /admin/audit.

Getting Started

Using Sherpa

Administration

Deployment

Share Sherpa conversations securely with teammates

Expiry

Audit log

Build docs developers (and LLMs) love

Getting Started

Using Sherpa

Administration

Deployment

Documentation Index

​How sharing works

​Creating a share from the UI

​Creating a share via the API

​Expiry

​Personal workspace restriction and sanitized sharing

​Revoking a share

​Audit log

Build docs developers (and LLMs) love

How sharing works

Creating a share from the UI

Creating a share via the API

Expiry

Personal workspace restriction and sanitized sharing

Revoking a share

Audit log