Page marks and proofing

Page marks let each reviewer rate every page of a document with one of three verdicts—pick, maybe, or reject—without leaving a written note. This suits contact-sheet selection, layout review, and page-by-page approvals. Verdicts are restored when a reviewer returns, and follow them across devices when they arrive through an email invite.

How viewers mark pages

When you enable page marks, viewers see a compact "Rate page" control near the top right of the viewer. It shows three buttons: Pick (✓), Maybe (~), and Reject (✕). Viewers click to set a verdict on the page they are on; setting a different verdict replaces the previous one, and clicking the active verdict again clears the page's rating altogether.

A viewer's own marks are loaded back into the control whenever they reopen the document; see Persistence and durability below for how far that reaches.

Annotations are a separate toggle in the same Proofing settings. When both are on, reviewers can mark pages and draw region-specific notes, and either action counts as proofing activity for the webhook below. See Annotations for details.

Reviewing verdicts

Once viewers have marked pages, you see aggregated results in Readership. The summary shows:

• Per-page counts: for each page, how many reviewers picked, marked maybe, or rejected it
• Per-reviewer breakdown: each reviewer's own tally of picks, maybes and rejects. Reviewers who arrived through an email invite are identified by their email address; everyone else appears as an anonymous reader with a short opaque key

You can export the full results as CSV—one row per mark, with the columns viewer, page, mark and updated_at. Identities are escaped against spreadsheet formula injection.

To reach the report, open the Readership page for a document with page marks enabled: the Proofing section holds the per-page table, the per-reviewer breakdown and a Download CSV button. See CSV export for the other exports.

Persistence and durability

Marks are keyed to the viewer's durable identity rather than to a single visit, and the viewer's own marks are reloaded whenever they reopen the document. How far that identity reaches depends on how the reader got in:

• Via an email invite: the identity is derived from the invite (its tracked link, or the invite email recorded earlier in that browsing session), so it is the same person on every device. A reviewer who marked pages on their phone sees those marks on desktop. See Email invites.
• Via a plain share link: the identity is a per-viewer key held in the reader's browsing session. Marks survive repeat visits in that browser but do not follow the reader to another browser or device.

Only you ever see who a viewer key belongs to; identities are never exposed to other viewers.

Limits and webhooks

Page marks are Pro-only. You must be on Pro and enable the "Page verdicts" toggle (marksEnabled) in the Proofing settings on the Configure & Share page. Marking is rate-limited to 1000 marks per viewer per document in any rolling hour, which covers bulk marking on long documents; clearing a verdict is not counted against it.

Marking stays live only while the owner holds Pro. If you downgrade, the control stops being served and no new marks are recorded, but existing marks are kept and reappear if you return to Pro. Turning the toggle off has the same effect and deletes nothing.

The first time a viewer leaves any proofing feedback on a file—a mark or an annotation—EveryPage fires a proofing.updated webhook event to your configured endpoints, with kind (mark or annotation), pageNumber and viewer. It fires once per viewer per file, not once per action, so a reviewer marking 200 pages triggers exactly one event. Your own marks on your own document never emit. See Webhooks for the full event reference.

Reading marks from the API

Because proofing.updated fires only once per viewer and carries no verdicts, it tells you that someone has started marking—not what they decided. Read the verdicts with GET /api/v1/files/{uuid}/page-marks, which returns per-page tallies, a per-viewer breakdown and document totals. Add ?format=csv for the same data as the Download CSV button. The endpoint is Pro-only and owner-only, and takes the readership:read scope.

The pattern for an automation is therefore: trigger on proofing.updated (or on a new comment), then pull the marks. All four integrations expose it—Zapier as the Get Page Marks search, Make as Get Page Marks, n8n as File → Get Page Marks, and the MCP server through everypage_get_readership with includeProofing. The photo proofing automation guide walks through a full workflow.

Treat the response as personal data: a reviewer who arrived through an email invite is identified by their email address.

For plan details and feature access, see Plans and limits.