What we collect, and what we don't.

PreArrive handles host accounts and guest acknowledgments. This page says, in plain language, what data passes through the product, why, who else touches it, and how long it stays.

At a glance

This policy describes how PreArrive actually handles data today. Plain language; no dark patterns. If anything here is unclear, email [email protected] — a human reads it. For the specific list of browser cookies we set (and which require your consent), see the cookie policy. Last updated: May 22, 2026.

PreArrive is run by Parameter LLC.

PreArrive is a product of Parameter LLC, a US software company based in the State of Florida. Parameter LLC is the data controller for the information described here. Questions about this policy go to [email protected]; security matters go to [email protected].

Two kinds of data pass through the product.

Host account data. When you sign up we store your email address and name, the properties and packets you build (house rules, itemized fees, welcome content), the reservations you enter, and your billing status. Sign-in is passwordless — we do not store passwords.

Guest data. When a host sends a packet, the guest reviews and signs it. To do that we collect the guest's name and email address, the IP addresses recorded when they open and when they sign, the drawn-signature image, and a two-event audit trail of the open and sign events. We also store a SHA-256 hash of the exact packet text the guest signed. Guests are not PreArrive account holders — their data is collected on behalf of the host who sent the packet.

Optional photo at signing. Paid hosts can require a plain camera photo before signing. This is not an ID scan and not biometric matching. We store the photo encrypted, strip EXIF location, and delete it one year after checkout by default unless the host configured a shorter window or a dispute/legal hold applies. The guest deletion path is linked from the signing-confirmation email. See the photo policy.

We also keep ordinary server logs and first-party analytics about how the marketing site and app are used. Google Analytics 4 runs only after a marketing-site visitor chooses Accept all in the cookie banner. We do not run third-party ad or tracking pixels.

Bot-challenge signals. The help-widget escalation form runs Cloudflare Turnstile to block automated abuse. Turnstile collects the visitor's IP address and a set of browser and device signals (challenge solve patterns, hardware characteristics, header values) to score whether the request looks human. We do not see those signals; Cloudflare returns only a pass/fail token. Cloudflare's processing of this data is governed by the Cloudflare Turnstile Privacy Addendum, which is incorporated into this policy by reference.

Each field has a job.

Host account data exists to run the service: to let you sign in, build packets, send reservations, and manage billing. Guest data exists to produce one thing — a tamper-evident certificate that records that a specific guest read and acknowledged a specific set of rules and fees before check-in. The IP addresses, timestamps, signature image, and content hash are what make that certificate evidentiary rather than decorative. We do not use guest data for marketing.

A short list of sub-processors.

We keep the vendor list explicit and describe each processor by purpose, region note, and data category. Each of these processes data only to provide its service to us. We do not sell your data, and we do not share it with marketers, data brokers, or insurance carriers.

Where PreArrive stores data
System Stores Examples Residency
Cloudflare Workers and Pages Application execution, static pages, request routing Signing flow, dashboard API, public verify endpoint, scheduled jobs Runs on Cloudflare edge infrastructure; core durable data is in the US-region storage listed below.
Cloudflare D1 Relational application records Users, teams, properties, packets, reservations, signatures, packet snapshots, audit metadata, API keys, webhook delivery rows, first-party events US-region database for the production project.
Cloudflare KV Short-lived tokens, revocation mirrors, counters, and caches Magic links, session revocation keys, guest signing tokens, OAuth state, API rate-limit buckets, idempotency snapshots, webhook plaintext secret cache Cloudflare KV is globally replicated; values use short TTLs where possible.
Cloudflare R2 Object storage Property logos in a public asset bucket; optional photo-at-signing images in a private bucket as AES-256-GCM ciphertext R2 bucket data is configured for Cloudflare storage; private photo bytes are additionally encrypted before upload.
Transactional email provider Email delivery data Sign-in links, guest packet emails, signature confirmations, reminder emails, support notices Processed according to the email provider account region and policy.
Stripe Billing and checkout records Customer id, subscription status, checkout session id, invoices, payment method metadata Processed by Stripe under Stripe policies. Full card numbers do not touch PreArrive servers.
Analytics Product and marketing usage events First-party /api/events rows in D1; consent-gated GA4 page/event data for marketing pages only First-party events stay in D1. GA4 events are processed by Google Analytics after cookie consent.
PreArrive subprocessors, purposes, regions, and data categories
Subprocessor Purpose Region / processing note Data category Policy
Cloudflare Hosting, Workers, Pages, D1, KV, R2, DNS, TLS, edge security, and Cloudflare Access for operator/admin access. Core PreArrive durable data is configured for US-region storage where the Cloudflare service supports it; KV and edge services are globally distributed. Host account data, guest acknowledgment records, packet data, signatures, optional encrypted photo objects, property assets, logs, security events. Policy
Cloudflare Turnstile Bot and abuse prevention on help-widget escalation forms. Processed by Cloudflare under the Turnstile Privacy Addendum. Visitor IP address, browser/device challenge signals, pass/fail token. PreArrive receives the token, not the underlying signal set. Policy
Stripe Checkout, subscriptions, billing portal, invoices, tax/payment compliance, and webhook reconciliation. Processed by Stripe according to Stripe account and policy. Host billing email/name, Stripe customer/subscription ids, checkout metadata, invoice and payment status. Full card numbers stay with Stripe. Policy
Mailgun Transactional email delivery and delivery-status handling. PreArrive uses the configured Mailgun region for the sending domain. Sender/recipient email addresses, message subject/body, delivery metadata, suppression or bounce metadata. Policy
Teamwork Desk Support ticket handling for help-widget escalations and support requests. Processed by Teamwork according to Teamwork policies. Support requester email/name if supplied, ticket body, attachments if the requester provides them, support metadata. Policy
Google Analytics 4 Consent-gated marketing analytics and conversion measurement on public marketing pages. Processed by Google Analytics after the visitor chooses Accept all in the cookie banner. Page/event data, approximate device/browser data, anonymized IP handling, campaign/referrer fields. Not loaded when visitors choose Essential only. Policy
Google OAuth Optional host sign-in provider when Google SSO is enabled. Processed by Google according to Google policies. OAuth state/PKCE, Google account identifier, email address, and basic profile fields returned by the OAuth flow. Policy

Core application records are stored in the Cloudflare production project with US-region durable storage where supported. Edge execution, KV, email, payment, support, OAuth, and analytics providers may process data under their own regional infrastructure and policies. PreArrive does not claim SOC 2, ISO 27001, HIPAA, or PCI certification for the product today.

Retention depends on the data class.

Signed certificates and their audit trails are retained for roughly seven years from the sign date. Optional photo at signing uses a shorter default retention window. Short-lived tokens and rate-limit counters use short TTLs. The current schedule is listed below.

PreArrive retention and deletion by data class
Data class Default retention Deletion path Legal hold
Host account, team, and property configuration While the account is active. Closed accounts become read-only; export remains available for 90 days, then records needed for certificates are archived for the certificate window. Email privacy support to close, export, redact, or delete account data where deletion does not break a retained certificate or legal obligation. May be retained longer when required for billing, security investigation, dispute, or legal hold.
Reservations and guest contact details Kept with the related certificate/audit record for roughly seven years from signing when a reservation is signed. Guests may request access or deletion through the host or PreArrive. Redaction can remove recoverable PII while preserving hash/audit metadata. Disputes, active claims, fraud/security reviews, and legal holds pause destructive redaction.
Signed certificates, packet snapshots, signatures, hashes, and audit trail Roughly seven years from sign date. Hosts can export at any time. Deletion/redaction requests are reviewed so the certificate can remain verifiable without unnecessary PII. May be retained through the dispute, claim, insurance, or court window for the signed stay.
Optional photo at signing Deleted one year after checkout by default unless configured/held. Hosts may shorten retention per property; some plans can configure within documented limits. Guest deletion path from confirmation email, or email [email protected] from the signing address. If no hold applies, the encrypted R2 object is deleted within five business days while hash/redaction metadata remains. Active disputes, support investigations, and legal holds pause photo deletion until the hold lifts.
Claim Kit metadata and evidence manifest Current Claim Kit metadata is local to the host browser unless it is sent transiently to export a claim packet PDF. Metadata may include incident notes, checklist state, claimed amount, platform case id, filenames, file sizes, MIME types, descriptions, and SHA-256 hashes. It does not include evidence file bytes. Remove inventory rows in the browser, clear site storage, or delete exported claim packet PDFs. PreArrive does not currently store original incident evidence files. Not applicable to local-only evidence files unless the host submits them separately to a platform, insurer, or court.
Operational, security, API, webhook, and analytics logs Short-lived counters use minutes-to-days TTLs. Product/security/event rows are pruned or aggregated as operationally needed. Privacy requests can remove or aggregate personal fields where they are not needed for security, abuse prevention, or accounting. Security investigations, abuse prevention, fraud review, and legal obligations may require longer retention.
Billing and support records Retained as required for accounting, tax, chargeback, and support history. Billing identifiers can be disconnected from the account where allowed; Stripe remains the system of record for payment records. Tax, accounting, chargeback, fraud, and legal obligations may require retention.

Access, export, and deletion.

Hosts can export their data — including certificates and audit trails — from the product. If you want a copy of the data tied to your account, or you want it redacted or deleted, email [email protected] and a person will handle it. Guests whose data was collected through a host's packet can ask us, or the host who sent the packet, for access or deletion. We honor those requests subject to the retention rules above — some audit-trail metadata is kept so a deletion stays provable.

If a dispute, insurance filing, platform claim, security investigation, or legal hold is active, destructive deletion may be paused. We will explain that path and remove recoverable data once the hold lifts.

Security posture, stated plainly.

Core application records use Cloudflare durable storage. The operator admin panel sits behind Cloudflare Access — operator access requires an authenticated identity and is logged. Packet text is hashed with SHA-256 at send time, so any later change to a packet is detectable. No system is perfectly secure, but we keep the surface small on purpose: no ID scans, no biometric matching, no third-party ad trackers. Report a vulnerability to [email protected].

PreArrive trust contacts
Need Contact Use for
Privacy requests [email protected] Access, export, redaction, deletion, and questions about host or guest data.
Security reports [email protected] Vulnerability reports, suspicious account activity, and responsible disclosure.
Product support [email protected] Signing issues, accessibility fallback, dashboard help, and claim-kit questions.
DPA requests [email protected] Processor terms, customer privacy review, subprocessor questions, and regulated-market review.
Incident reporting [email protected] Security incidents, suspected data exposure, and urgent evidence-access concerns.

If this policy changes.

If we change this policy we will update the date at the top of this page; material changes will be communicated to active hosts by email. Questions, requests, or corrections go to [email protected].

Plain policy. Plain product.

If the privacy story above sounds right, the product follows the same posture. Free covers one property, no card.