An automated document workflow proposes comments and edits before a human review and final PDF handoff

Document automation is safer when software proposes a change and a person decides whether it belongs. Google has now made that review pattern available through the Google Docs API, giving developers a way to create comments and suggested edits instead of silently replacing approved text.

What Google released

On 30 September 2026, Google made comment and suggestion support generally available in the Docs API. Applications can read comment threads, create comments and replies, modify or delete posts, write edits in suggestion mode, and accept or reject suggestions. Google also announced comment APIs for Sheets and Slides, so review workflows can span common Workspace files.

This is an API capability, not a new review bot that appears automatically in every document. An organization or developer still has to build or authorize the application, choose its permissions and decide when it may act. Google's separate Docs Model Context Protocol server remains in developer preview, so that preview should not be treated as the same thing as the generally available API.

A review-first document workflow

1. Protect the source. Keep an approved version or revision identifier before automation starts. Limit the application to the documents and operations it genuinely needs. 2. Propose instead of overwrite. Use comments for questions and suggestion mode for textual changes. A suggestion makes the difference between the current wording and the proposed wording visible to a reviewer. 3. Assign an accountable reviewer. Ask a named person to check facts, figures, names, dates and policy language. Resolving a thread should mean the underlying issue was checked, not merely that the notification was cleared. 4. Check the update result. Google's documentation warns that a batch operation can partly fail: document-model changes may be committed even when an associated comment or suggestion fails to save. Applications should inspect the returned update status and surface anything that needs retrying or manual review. 5. Export only after approval. Once suggestions are accepted or rejected, export the intended final file. Reopen the PDF and inspect page breaks, tables, links, images and any content near the margins. 6. Keep a useful record. Retain the source revision, reviewer, decision and final filename according to the organization's retention rules. A comment thread is helpful context, but it is not automatically a complete audit or compliance record.

Limits worth planning for

Not every Docs operation works in suggestion mode. Google's current guide lists unsupported requests, including adding or deleting document tabs and several document-style changes. Permissions also matter: accepting suggestions requires edit access, while deleting one generally requires authorship. Suggested wording can still be inaccurate, biased or inappropriate, so API availability does not remove the need for subject-matter review.

FileStation is not connected to Google Workspace and does not create or approve Docs suggestions. After a team has approved and exported a PDF, Organize PDF can help inspect page order and rotation, and the CLEAR final-document check provides a deliberate pre-share review. Download and reopen the exact file that will be sent.

The useful change is not automation without people. It is automation that leaves the proposed change visible, gives someone authority to reject it and makes the final handoff easier to verify.

Primary sources: Google Docs API release notes, 30 September 2026 and Google's guide to comments, suggestions and partial-failure status.