Binds the pair, then signs it
The payload is user plus product, and the signature covers both along with a context string, so a token minted for one surface cannot be replayed against another.
Reporting and agency
A link anyone can open, over data nobody else can query
0
new database tables needed to make reports shareable
The token carries the (user, product) binding and is verified against a server secret before any read.
Sharing a report without a login is the kind of feature that goes wrong quietly. The obvious implementation puts a product id in a URL and fetches by it, and then someone changes a digit and reads a stranger's audit. We had one constraint that ruled that out from the start: every query in the report is user-scoped in SQL, so a handler with only a product id cannot fetch anything at all.
So the link carries the missing half. The token encodes the user and product together and is signed with a server secret; the public handler verifies the signature, then reads through the same user-scoped queries a logged-in session would use.
Where it lives: The share button on any report. Links live under /s/.
What it looks like
Illustrativecuescout.com/s/8f2a41c9No login
The client sees
- Their visibility score and trend
- Every source behind the answers
- The pages to write next
The link cannot reach
- Your other clients
- Billing and account settings
- Anything outside this one product
The token carries the user and product binding and is checked against a server secret before any read. One link per brand, and it survives a re-scan.
What it does
Changes nothing about the query path
After verification the handler calls the same store methods with the bound user id. There is no second, looser read path to get wrong.
Needs no storage
A signed token is self-describing, so there is no table of live links to keep consistent and nothing to clean up.
How it works
- 01The token is base64url payload plus signature, verified with a constant-time comparison.
- 02Tokens are unguessable: forging one means forging an HMAC over a secret that never leaves the server.
- 03The same signing approach carries the unsubscribe links in outreach email, so there is one mechanism to reason about rather than two.
What it does not do
- Possession is authorisation. Forward the link and the recipient can read the report.
- Revocation is coarse. Rotating the secret kills every outstanding link, and there is no per-link revoke or expiry yet.
- There is no access log per link, so you cannot see who opened it.
What you get
One stable link per configured brand.
Read the full plan comparison.
Frequently asked questions
Can someone guess a link?
Not realistically. Guessing means producing a valid HMAC-SHA256 signature without the secret.
Does the link expire?
Not on its own. Rotating the server signing secret invalidates all links at once, which is the only revocation available today. If per-link expiry matters to you, it is worth asking about before you buy.
Does the recipient see my other products?
No. The token binds one product, and every query behind it is scoped to that pair.
Related features
Reporting and agency
Every feature we publish Opportunity Report
The whole picture for one product on one page, shareable with a prospect or a client who has no login.
Reporting and agencyMulti-product workspace
One account, many products: separate question libraries, separate citation corpora, separate reports, one bill.
Reporting and agencyOutreach drafts
The sales side: drafted emails carrying a real report, held in a review queue, sent on a paced loop with unsubscribe handling.
Run it on your own product
Start with the free visibility check to see whether the engines name you today, then run the scan that shows which pages they used instead.