Skip to main content
An agency often needs the client’s yes before a change goes out, and the client should not need an Attensira account to give it. The client reviewer link is that yes.

​
What the reviewer sees

There is one link per workspace. Whoever holds it can see that workspace’s suggested changes: what the change is, why, where it lands, the current and proposed text, and the source links (only http and https links are shown). For each one they can decline with a reason: wrong, not now, already done, or never touch this. They can approve only what the link’s scope allows. The link approves at most approve:own_site:safe: a change to the workspace’s own site whose change class is safe (hygiene such as structured data, meta tags, alt text and internal links, with nothing that names a price, a number with a unit, a promise, a competitor or a product), and only when it can be undone (effect class pure or reversible). Everything else the page shows says Your agency approves this one instead of an Approve button, and the client can still decline it. That includes a claim-class change (it says something a customer could hold the business to), a change nothing classified, a change to another site, outreach, and anything compensable or irreversible. You approve those in the app. An approval the link is not allowed to give answers 403 with code: "scope_denied" and details.reason: "client_link_scope". They cannot see settings, billing, analytics, tasks, outreach contacts, autonomy, or any other workspace.

​
The client portal

The same link also opens the client portal at app.attensira.com/portal/<token>. It uses the same token, so creating, replacing, turning off and rotating the link apply to the portal too. The portal shows, in order:
  1. The changes waiting for the client’s yes, with the same approve and decline as the reviewer page and the same scope.
  2. This week’s scorecard: the newest stored weekly scorecard for the workspace, without next week’s plan. Before the first one is composed, the portal says it arrives on Monday. The portal shows it even when public scorecard links are off for the workspace, because the portal is a link you gave your client.
  3. Recent receipts: the Receipts verified lines from the scorecards of the last four weeks, newest first. A week with none is left out.
The portal never shows autonomy controls, settings, or a way into the dashboard. If the link expired, was replaced, or was turned off, the portal says This link no longer opens and offers one button, Ask for a new link. Pressing it adds a notice to the workspace’s Inbox: Your client for <workspace> asked for a new client link, where <workspace> is the workspace name (or its domain when it has no name). Asking again while that notice is open does not add a second one. Send the client a new link from Client link. A link that was signed before a Rotate on the receipt link cannot ask, because its signature no longer checks out: the client has to contact you directly.

​
Creating and revoking it

Create it from the workspace’s card on Clients, under Client link, or from Settings → Agency (/settings/agency), under Client portal links, which lists every workspace in the org with its link. A viewer cannot create one. In Settings → Agency, each workspace shows its live link with Copy and the date it works until, or Create link when it has none. Rotate is the same as New link: it asks first, then replaces the link, and the old one stops working immediately. Turning a link off is on the Clients card.
  • The link is valid for 90 days.
  • New link replaces it. The old link stops working immediately.
  • Turn off revokes it.
Turning it off or replacing it does not touch any other link the workspace shared. Rotate on the shared receipt link stops every shared link at once, this one included. After a rotation, Client link shows the same link signed again, with the same expiry date: send the client the link shown again. You don’t need New link.

​
What an approval does

An approval through the link, or through the portal, is the same approval as one in the workspace. It is recorded with the name client:<workspace name> (for example client:Acme), so you can tell the client said yes. A decline is recorded the same way.
  • Approvals are refused when the org’s credits are used up.
  • Declines always go through.

​
Over the API

Dashboard routes (signed-in session):
  • GET, POST and DELETE /v1/projects/{id}/reviewer-link read, create or replace, and revoke the link. Each answers {active, token?, url?, portal_url?, issued_at?, expires_at?}. url is the reviewer page (/r/<token>) and portal_url the client portal (/portal/<token>).
Public routes, where the token is the credential (see shared links):
  • GET /v1/share/{token}: {kind: "review", review: {workspace, shared_by, expires_at, items}}, the suggested changes. Each item carries approvable and, when it is false, held, the sentence the page shows; its change carries class (safe or claim).
  • GET /v1/share/{token}/portal: the client portal.
  • POST /v1/share/{token}/items/{itemId}/approve
  • POST /v1/share/{token}/items/{itemId}/decline with {"reason": "wrong" | "not_now" | "already_done" | "never_touch"}.
  • POST /v1/share/{token}/request-link: ask for a new link.
Only a reviewer link can approve or decline. A link to a board, report or rewrite from the same workspace is refused, and so is an item the page does not show. These review routes are not MCP tools: they belong to a client who has no account. An agent approves the same changes with act and its own approve scopes.