How Client Reviewers approve content without GitHub access

Client Reviewers are the people who sign off on your content — the brand manager, the small-business owner, the marketing lead at the company you publish for. They almost never have a GitHub account, and they should not need one. In Acrosite, a Client Reviewer can read a draft, leave comments, and Approve or Request Changes without touching a repository, a branch, or a single line of Markdown. This article explains how that role works, what a reviewer actually sees, and why approval happens entirely inside the app before anything is committed to your branch.

The friction in most content sign-off processes comes from a mismatch: the work lives in a developer's world (Git, pull requests, file paths), but the approver lives in a business world (email, documents, "looks good"). Acrosite closes that gap by giving the approver a focused, read-and-respond view of exactly the content assigned to them — and nothing else. No repo access, no billing, no workspace settings, no other clients' work.

What a Client Reviewer can and cannot do

A Client Reviewer is a deliberately narrow role. It exists for one job: reviewing assigned content and recording a decision. That narrowness is the point — it keeps the experience simple for the reviewer and safe for you.

A Client Reviewer can:

• Open the drafts assigned to them within a single Project.
• Read the full rendered content, including title, body, and relevant fields.
• Leave comments on a piece to ask questions or request specific edits.
• Approve a piece, or Request Changes with their notes attached.

A Client Reviewer cannot:

• See or access the connected GitHub repository, branches, or commits.
• View billing, plan, or invoice information.
• Open workspace settings, deployment configuration, or connection details.
• See content from other Projects, other Clients, or pieces they were not assigned.

This is access by assignment, not access by login. Inviting someone as a Client Reviewer does not hand them the keys to your Workspace; it hands them a reading list. Internally, your own staff still work through the Review Queue and the rest of the dashboard, while the reviewer sees only their slice.

Invited per Project, scoped to assigned content

Acrosite's structure matters here. A Workspace contains Projects, and each Project maps to one client website or repository. Clients group related work together. Client Reviewers are invited per Project, which is what keeps their visibility contained.

When you invite a reviewer to a Project, they do not automatically see everything in it. They see the specific Content Items assigned to them for review. If you run three client websites out of one Workspace, a reviewer invited to one Project has no awareness that the other two exist. There is no Workspace-wide directory of content for them to browse, and no way to navigate sideways into another client's material.

This per-Project model also keeps your team structure clean. Team Members are your internal collaborators with roles such as Owner and Admin; they operate across the dashboard. Client Reviewers sit outside that internal hierarchy entirely — they are guests with a single, well-defined purpose.

How approval happens before anything reaches the branch

The most important thing to understand about Client Reviewers is *when* their decision happens in the publishing lifecycle. It happens early — before a commit, not after.

In Acrosite, drafts are private inside the app until they are published. Publishing is the step that commits a Markdown or MDX file (with its YAML frontmatter) to your connected repository on the configured branch and content path. A Client Reviewer's Approve or Request Changes decision occurs on the draft, while it is still private in the app. Nothing has been written to the branch yet.

A typical flow looks like this:

1. A Team Member writes or edits a Content Item and finishes the draft.
2. The piece is assigned to a Client Reviewer for sign-off.
3. The reviewer opens the draft, reads it, and either Approves or Requests Changes (often with comments).
4. If changes are requested, the Team Member revises and resends; the loop repeats until the piece is approved.
5. Once approved, your team triggers publishing — and only then is the file committed to GitHub on the configured branch.

Because the reviewer's decision is recorded against the private draft, the client is never reviewing something that is already live, and they never need Git access to participate. The branch stays clean: it only ever receives content that has already cleared review.

This also pairs naturally with Scheduled publishing. An approved draft can be held in the app and committed at a chosen time, with no early commit to the branch. The reviewer signs off once; the commit happens later, on schedule.

The reviewer's experience

From the Client Reviewer's side, the experience is intentionally calm and uncluttered. They receive an invitation, sign in, and land on the content assigned to them. There is no dashboard full of settings, no repository browser, no plan-and-billing panel — just the pieces waiting for their attention.

When they open a Content Item, they read the rendered draft rather than raw Markdown. They are not confronted with frontmatter syntax, file paths, or commit history. If something needs changing, they leave a comment in context or choose Request Changes. If it's ready, they choose Approve. That decision is captured and visible to your internal team.

For the reviewer, the mental model is simply: *read this, then tell us yes or not-yet*. That is a far lower barrier than asking a non-technical stakeholder to comment on a pull request or navigate a Git host.

Why "no GitHub access" is a feature, not a limitation

It can feel counterintuitive to celebrate withholding access, but for client-facing work it is exactly right:

• Security. Reviewers never see tokens, repository contents, or deployment configuration. There is nothing sensitive for them to leak or break.
• Simplicity. A client who has never seen a terminal can still approve content confidently.
• Boundaries. Your internal operations, other clients' work, and your commercial terms stay private. The reviewer sees content, not your business.

If you want to compare how this differs from giving clients direct repository or CMS logins, the comparison pages lay out the trade-offs in more detail.

A practical setup checklist

To get a clean review process running with Client Reviewers, work through this short checklist:

• Confirm the Project is connected to the right repository, branch, and content path (for example, content/posts/).
• Decide which Team Members own drafting and which pieces need client sign-off.
• Invite the client's stakeholder as a Client Reviewer on that specific Project.
• Assign the relevant Content Items so the reviewer sees exactly what they should.
• Make Approve a required gate before any team member triggers publishing.

Here is a small example of the kind of frontmatter your team manages internally — the part the reviewer never has to touch:

---
title: "Spring Collection Launch"
slug: spring-collection-launch
status: draft
date: 2026-06-15
---

The reviewer reads the finished result of this; your team handles the fields. Once approved and published, the commit lands in the repo and your Publish Logs record the steps — validated content, committed to GitHub, commit SHA saved, deployment triggered — without exposing tokens or raw payloads. Deployment Logs then record the rebuild result, giving you full Deployment visibility.

How this fits a Git-backed workflow

The reason this role can be so simple for the client is that the complexity lives elsewhere, handled by your team and by Acrosite. Content still lives in your own GitHub repository as Markdown or MDX with frontmatter. GitHub publishing is driven by a Workspace-level GitHub App connection scoped to the connected repository. The framework on the other side — Next.js or another Git-backed, static-friendly stack — rebuilds when the deployment trigger fires.

None of that surfaces to the Client Reviewer. They experience the content, not the pipeline. That separation is what lets a developer keep full control of the repository while a non-technical client still has a real, recorded say in what goes live. If you want to see how the whole flow connects end to end, the how it works overview walks through it, and the pricing page shows which plans include the collaboration features you'll need.