Shared pages

A shared page is a read-only, public URL for an Album page. Anyone with the link can open it in a browser without signing in and without an Albumi account. It is how you give stakeholders outside your workspace — partners, vendors, leadership who do not use the tool — a specific view of your architecture, without granting them access to anything else.

Shared pages are narrow by design. One album page, one token, one anonymous viewer. Sharing a whole workspace is a different feature that does not exist; the unit is always a page.

How sharing works

Any Live or Change-Request album page has a Share button in the page header. Clicking it opens a small dialog:

• If the page has never been shared: the dialog offers Create share link. Click it, and Albumi generates a fresh 96-bit random token and returns a URL shaped https://my.albumi.app/s/{token}. Copy it; that is the link you send.
• If the page already has a share: the dialog shows the existing link, the number of times it has been viewed, the timestamp of the most recent view, and a Revoke button.

There is no settings panel, no expiry picker, no password. A share link is live until you revoke it.

Only Admins and Contributors can create or revoke shares. Viewers see the page but not the Share button — opening a workspace to the outside world requires at least Contributor authority.

What the recipient sees

A person opening /s/{token} in a browser lands on a viewer page that looks like the editor, minus the editing. The diagram, layout, node positions, edge labels, and sticky notes are all preserved. There is no sidebar, no workspace navigation, no way to leave the page for another part of the landscape. What you shared is what they see; they cannot navigate to a sibling page or a neighbouring entity.

They also do not see who shared the link, when, or from which workspace. The page is served through an anonymous pipeline that deliberately strips identifying metadata.

What gets stripped

The public response is not a copy of the editor payload. It is a purpose-built shape produced by a per-request anonymiser that removes fields the recipient has no business seeing. The strip list:

• On Interfaces (the technical contracts on Applications): Endpoint, Authentication. The recipient sees the interface name and protocol; they do not see URLs, credentials metadata, or auth schemes.
• On Data Objects: Classification, PiiFlag, PciFlag. Whether a data object contains personal data or payment data is information the receiver does not need to run a sanity check on your architecture, and leaking it sideways through a screenshot of a share link is exactly the failure mode this strip prevents.
• On Integrations: TransformationNotes and middleware UUIDs. The name of the middleware is preserved (so the diagram still reads), but the underlying identifier is not.
• On every entity: WorkspaceId, AcrId, FocusEntityId, DeletedAt, CreatedByUserId, ChangeId. Anything that would let an outsider correlate your shared page to other pages, other workspaces, or internal change-request state is removed.

The anonymiser is stateful per-request: every internal UUID in the response is replaced with a stable short public ID (n1, n2 for nodes; e1, e2 for edges; d1, d2 for data objects; i1, i2 for interfaces; note1, note2 for sticky notes). If the same internal entity is referenced twice on the page, both references become the same public ID. Public IDs do not persist between responses — opening the same link tomorrow produces a different set of n1/n2/… mappings under the hood. This is deliberate. It means a recipient cannot build a database of your entity identifiers by scraping the link over time.

Tracking

Each share keeps two counters, visible to you in the Share dialog:

• View count — incremented on every page load. A recipient refreshing the link bumps the counter. Bots from preview unfurlers (Slack, Discord, Teams) also bump it.
• Last viewed at — timestamp of the most recent increment.

Neither of these is a strong identity signal: you cannot tell who viewed, from where, or whether two views were the same person. They are an anti-surprise mechanism — if you expected nobody to open a link and it has been viewed 40 times, you now know. They are not an audit log.

Revoking a share

Click Revoke in the Share dialog. The token is immediately invalidated; any subsequent request to /s/{token} returns 404 and any browser tab still showing the link will fail to reload. Revoking does not delete the page, does not notify the recipient, and does not produce a warning on the other side — it silently cuts the link.

Re-sharing the same page mints a fresh token — existing URLs are not reused. This is by design: if you once shared and revoked, the old URL cannot be accidentally resurrected by clicking Share again.

When to share, when not to

Shared links are designed for specific, scoped, read-only exposure. Good uses:

• Sending a target-state diagram to a vendor who is implementing part of it.
• Including a lineage page in an incident review with leadership.
• Giving a consultant a view of one domain during a workshop, without onboarding them into your workspace.

Bad uses:

• Sending a link to someone who will then need to modify the page. Invite them with Contributor role instead; see Inviting your team.
• Including sensitive annotations or comments on the page that you would not post in a public Slack. Sticky notes on a shared page are visible to the recipient; treat them as public.
• Using a share link as a stable URL you can reference in internal documents. Revoke and re-share mints new tokens; the URL is not a permanent anchor. For internal consumption, an in-app deep link to the page is the right reference.

Security characteristics

A few properties worth knowing, especially if your organisation has policy questions about public links:

• Token entropy. 96 bits of randomness, base64url-encoded, 16 characters. Brute-forcing the URL space is not a realistic attack vector.
• Rate limiting. All /public/* endpoints are rate-limited per IP (300 requests per minute in production). Scraping at volume is blocked.
• No referrer tracking. Albumi does not capture the HTTP referrer of the incoming request; we do not know where the link was clicked from.
• No password protection. Tokens are the only access-control mechanism. If that is not acceptable for your use case, the answer is not to share the page publicly.

Limits

• Share links point to one page, not a whole album. If you need to share three pages with the same audience, create three links.
• A page can have one active share at a time. Revoking before re-sharing is required if you need a new URL for the same page.
• Shared pages are served through a separate rate-limited pipeline that is not subject to workspace quotas — but they also do not contribute to your workspace’s usage metrics.