How do I share Devin's output with people who do not have Devin?

Publish it. A session view is gated behind the product's own access model; a published report is a page anyone with the link and access can open, comment on and come back to.

Devin opens pull requests. Why do I need anything else?

For code changes you do not. But a large share of what Devin produces is not a diff — an investigation, a dependency audit, a plan — and a PR is a poor container for a document nobody is merging.

How does Devin publish?

With one REST call from inside the session, or from the repo's own workflow after the run. `POST /api/v1/reports` with the HTML returns a URL.

Where should the token live?

In the secret store the workspace already uses, scoped to `reports:write`. Never in the repo.

Can the report be updated on a follow-up session?

Yes — PATCH the same report id. The URL stays stable and each session appends a revision, so the link in the ticket keeps working.

Share what Devin produced

Devin runs in its own cloud workspace and reports back inside its own session view. That works well while the work is happening and badly afterwards, because the audience for the result is rarely the set of people with a seat.

For code, the pull request is the answer and always has been. For everything else — the audit of every third-party call, the reason the flaky test is flaky, the plan for splitting the monolith — a PR is the wrong container. Nobody is merging a plan.

One call, from wherever the run ends

The workspace has outbound network, so the publish is a single request:

curl -sS -X POST https://commareports.com/api/v1/reports \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --arg t "Third-party call audit" --rawfile h report.html \
        '{title:$t, html:$h}')" | jq -r '.url'

Put that in the repo as a script and the instruction becomes short enough to live in the session's standing knowledge: finished documents get published with scripts/publish-report.sh; reply with the URL. Full shape in the API docs; the token comes from API tokens and belongs in the workspace secret store.

Or do it from the workflow

If the run ends in a pull request anyway, publishing from CI and linking the report from the PR body keeps both halves in their right container — the diff in the PR, the reasoning on a page that non-engineers can open. See GitHub Actions reports.

Why the session view is not enough

Access is the product's, not yours. A published report has its own access setting, including link-shared and password-protected.
It renders and it lasts. The page is a snapshot with revision history, not a transcript inside a session that ages out.
Comments anchor to the finding. Reviewers mark the claim they doubt — see commenting on HTML.
The link survives the session. Six weeks later, the decision has a citation.

Worth knowing

reports:write is the scope. Tokens are revocable, expirable and rate-limited per token — see scoped tokens.
5 MB of HTML per report body.
Nothing re-executes on open.

Try it

Free — unlimited reports, commenters and revisions.

Read the API docs →