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 tab of a document's Configure & Share page and is toggled by the Ask for an email first switch. That switch 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 turning on the Ask for more than an email switch, which creates the fixed email field, then adding fields of type text, phone, company, or drop-down. A drop-down lists 2–20 options you write, and the viewer picks exactly one. 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 10 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). The lead capture for PDFs overview shows what a gated document looks like from the viewer's side before you set one up.

Saving any lead-capture fields forces the gate on—Ask for an email first 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.

Sign-in card look

The card a reader sees before the document — the plain email prompt, the lead-capture form, and the password card alike — can wear your colours and your image. The controls sit under Sign-in card look on the Privacy & Access tab, shown once the email gate or a password is on, and the preview pane switches to the card while you work on it:

• Page colour: the page behind the card. The card itself stays paper-and-ink so the form is readable on any colour.
• Button colour: the submit button. Its label flips between ink and paper by contrast, so no colour leaves it unreadable. The same colour underlines the "Report this document" link under the card (ink instead, if your colour is too pale to read on the card) and fills it on hover.
• Logo or photo: a PNG, JPEG, or WebP image (up to 5 MB) at the top of the card, either as a centred logo in place of the envelope or lock mark, or as a full-width banner across the top. Each document stores one; a new upload replaces it.

The card is styled separately from the viewer's own branding on purpose: it can look different from the document behind it, and the viewer's logo is not reused on it. Everything here is Pro, and all of it is public by design — the colours and the image are shown to anyone holding the link, before they sign in. The image is the one asset served ahead of the password and email gates; the document's own logo, background and hotspot media stay behind them. If your plan drops below Pro the card goes back to stock for readers immediately and the image stops being served before the gates; the settings are kept and return when you re-upgrade.

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: alice@acme.com and bob@sub.acme.com both pass if you've allowed acme.com, but eve@evilacme.com 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–300 characters.
Value (text, phone, company): up to 500 characters.
Drop-down options: 2–20 per field, each 1–100 characters and unique. The submitted value must exactly match one of the options.
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

Turning off Ask for an email first 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.