Email gates and lead capture

An email gate blocks document access until a viewer provides their email address or answers a multi-field form. The gate lives on the Privacy & Access panel of a document's Configure & Share page and is toggled by the Require Email to View checkbox. That checkbox is the single "gate is active" switch: a document gates on email if, and only if, it is on.

Two gate shapes

The gate takes one of two forms:

Plain email prompt. A single input asking only for an email address. When the viewer submits, their address is stored on the view session and watermarking can use it to mark every copy with the reader's identity (see reader identities).

Lead-capture form. A custom multi-field form that supersedes the plain prompt. You build it by checking the Custom Gate Form checkbox, which creates the fixed email field, then adding fields of type text, phone, or company. A form must contain exactly one email field; it is always moved to the front and forced required, and it cannot be renamed or removed. Fields you add are required too — the builder has no optional toggle. A form holds at most 5 fields including the email field. When a viewer submits, the captured data flows into your readership contacts and is accessible via your events feed (see events feed).

Saving any lead-capture fields forces the gate on—Require Email to View is set server-side, so a form can never exist behind an inactive gate. Clearing the form, and turning the gate off, are deliberately un-gated: an account that has dropped below Pro can always switch the gate off even though it could not switch it on.

Tier requirements

Enabling a gate requires Pro; collecting through one that is already on does not. If your plan drops below Pro, a document whose gate is on keeps gating and keeps recording captures — what you lose is the ability to enable new gates and to read the captures. They persist and become readable again when you re-upgrade.

Domain allowlist

You can restrict the gate to viewers with email addresses on specific domains. The Restrict Viewer Email Domains section appears once the gate is on; add bare hostnames like acme.com one at a time (up to 20 domains). Matching is domain-aware: [email protected] and [email protected] both pass if you've allowed acme.com, but [email protected] does not.

Leave the list empty to accept any email address. See email domain allowlist for the matching rules and what the check does and does not prove.

How data is stored

Plain-email captures (address only, no form) are stored on the view session record in your readership data but NOT in the events feed. If you later add a lead-capture form, existing plain-email captures remain queryable through the readership sessions interface, but they do not appear in the gate responses stream.

Lead-capture form submissions (one or more custom fields) are stored as contact records in the gate_responses stream. You can export them as CSV from the readership page or query them via /api/v1/gate-responses when you hold a Pro plan.

The validated email address from either gate shape is stored on the view session and can watermark the PDF.

Invited recipients

A viewer arriving via an email invite link (the ?i= token) pre-satisfies the gate. The interactive gate is skipped entirely on the server: nothing the viewer submits is validated or captured, no gate response is recorded, and no gate.completed event fires — an invited open emits invite.viewed instead. The invitee's email from the invitation itself becomes the session identity for watermarking. The current viewer still renders the gate form to an invited recipient before opening the document; submitting it changes nothing. See email invites for details.

Owner access

Signed in as the document owner, you bypass the gate and see the full document. The bypass requires a real owner account: an anonymous document (uploaded without logging in) has no owner, so an anonymous visitor is never matched against it as one.

Field constraints

Label: 1–60 characters.
Value (text, phone, company): up to 200 characters.
Email value: 3–254 characters, and it must contain an @ with a dotted domain after it. This is a plausibility check, not RFC-complete validation, and not proof the mailbox exists.

Field keys are auto-derived from labels (lowercase, snake_case, 1–40 characters, starting with a letter) and must be unique within the form. The email field's key is email. A submission is accepted or rejected as a whole: any field error rejects the request with the per-field messages, no session row is written, and the gate stays shut. Values for keys the form does not define are discarded rather than stored.

Webhooks

The gate.completed event fires when a viewer actively passes the gate and is not arriving from an invite. The event payload includes the source (link, qr, email, or embed) and the captured email and/or form fields.

Delivery requires a Pro plan at the moment the event fires: the check runs when deliveries are queued, so an event raised while your plan is below Pro is never queued and is not delivered later. Re-upgrading resumes future deliveries; it does not replay the ones that were skipped. The capture itself is unaffected — the lead is still recorded and becomes readable again through the readership page and the pull APIs. The event never fires for owner access, for invite-satisfied sessions, or for a document with no owner account.

See webhooks for integration setup.

Disabling and clearing

Unchecking Require Email to View disables the gate immediately. Existing captures remain in your readership data. If you later re-enable the gate, the same form configuration (or plain email prompt) takes effect again.

Captured rows cannot be deleted individually. Gate responses are tied to the document: deleting the document deletes them with it, as does deleting your account. Export what you need first — the readership CSV export carries the captured contacts as a second section after the session rows.