Notify & OTP

Email the secret link to recipients, and optionally require a one-time email code before the secret is shown.

This article applies to: Hosted (Solo, Team, and Organization)  ·  Pro Self-Hosted

Notify emails the secret link when you create a push or request. OTP (Authenticated Recipients) requires the viewer to prove they control an authorized email address before the secret is shown.

The two options are independent. You can email the link, require a one-time code, do both, or use recipient emails only as an allowlist and deliver the link yourself.

Not available on hosted Free. Open source Password Pusher has Notify today. OTP is being added to OSS soon. For OSS environment variables and daily caps, see Notify by Email.

How it works

On the push or request form, signed-in users can add Recipients (up to 5 email addresses) and then:

Option (UI label) What it does
Email the link (notify_recipients) Sends each recipient the secret URL when the push or request is created (Auto-Dispatch). Default is on.
Verify before viewing (authenticated_recipients) Before the payload is revealed, the recipient must enter their email and a 6-digit one-time code sent to that address. Default is off.

Recipient emails are optional unless Verify before viewing is on. OTP needs an allowlist to check against.

You can turn Email the link off and still add recipients for OTP only. Share the URL through chat, your own mail, or a ticket — Password Pusher then only gates access.

Recipient emails, Notify, and OTP cannot be changed after create.

Recipient OTP flow

When Verify before viewing is enabled:

  1. The recipient opens the secret URL.
  2. They enter their email address.
  3. If the address is on the allowlist, Password Pusher emails a 6-digit code that expires in 15 minutes. Codes are single-use and stored hashed.
  4. They enter the code. A signed cookie holds the verified session (about 15 minutes).
  5. If an unlock phrase is also set, that prompt comes after email verification.

If the email is not on the allowlist, the UI is the same — “If that email address is authorized, a verification code has been sent.” No code is sent. That avoids leaking who was authorized.

Failed verification does not consume a view. GET /api/v2/pushes/:url_token and the equivalent request retrieve return 403 (email_verification_required) when OTP is on. Recipients must complete verification in a browser.

Limits

Control Value
Recipients per push or request 5
OTP length / lifetime 6 digits / 15 minutes
Failed attempts per code 5, then the code is invalidated
Request a code 5 per 15 minutes
Submit a code 10 per 15 minutes

Where to configure

Defaults and enforcement come from Application Policies, separately for pushes and requests.

Deployment Who Where
Hosted (Solo, Team, and Organization) Workspace admins Admin → Application Policies → push and request options → Notify Recipients and Authenticated Recipients
Pro Self-Hosted Instance admins Administration Center → Application Policies → the same sections (instance-wide)

Each section has Enable?, Default Value, Force The Default Value?, and Hide Option?.

Policy Effect
Enable? Off hides the control and disables the feature.
Default Value Pre-checked state on the form and the API default when the field is omitted. Notify defaults to on; OTP defaults to off.
Force The Default Value? Members cannot change the option.
Hide Option? Hides the checkbox while the default (and force, if set) still apply.

Turning Notify off does not turn off OTP. Recipient addresses can still be used as an allowlist.

Email delivery

Hosted workspaces send from Password Pusher mail by default. Organization (and Pro Legacy) can send Auto-Dispatch, OTP, and invitation mail from Google Workspace or Microsoft 365 — see SSO & Email Delivery.

Hosted workspaces can set a default language for those emails (Workspace → Email language). A per-send language still overrides it.

Pro Self-Hosted sends through Administration Center → Settings → Email. Configure SMTP there (not PWP__* environment variables). See Pro Self-Hosted Configuration. Instance default language is used when a send does not pick a locale.

Audit log

OTP writes identity events next to view events:

Event Meaning
Verification Code Sent A code was emailed to an allowlisted address
Recipient Verified The recipient entered a valid code
Failed Verification A code check failed

API v2

Create a push or request with:

  • notify_emails_to — comma-separated addresses (max 5)
  • notify_emails_to_locale — optional language for the email and secret-link copy
  • notify_recipients — true / false (omit to use policy default)
  • authenticated_recipients — true / false (omit to use policy default; requires recipient emails)

Example: OTP allowlist without Auto-Dispatch:

curl -X POST https://eu.pwpush.com/api/v2/pushes \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "push": {
      "payload": "MySecretPassword123",
      "notify_emails_to": "ada@example.com",
      "notify_recipients": false,
      "authenticated_recipients": true
    }
  }'

Retrieving an OTP-protected secret via API is not supported. Preview and audit still work for authorized users.

See the in-app docs at https://pwpush.com/help/api or API v2.

See also