Last updated September 19, 2026
Privacy policy
Unfinished listing drafts
When signed-in owners use the standard new-listing form, unfinished answers are saved privately to their account so they can resume on another device. These records include the form answers, current step, revision and update time. They may include contact information and private property notes, but exclude listing consent and private access tokens. Saving does not publish a listing or accept an agreement. Owners can discard unfinished drafts; submitted drafts retain their connection to the created property for submission recovery. Private-interest invitations also save unfinished hunt answers and progress. Those drafts require the same active private invitation and parcel workspace to resume, including on another device. They exclude consent and access tokens. You may discard these answers without deleting the parcel workspace. Expired or used invitations no longer open or modify them; saved copies are removed after expiry or promotion during the next invitation-draft request.
Accounts and email verification
Account access links private property drafts, requests and participant records to an account identifier. When email sign-in is enabled, we store your email address, verification time, account identifier and account status. Verification records contain hashes of the sign-in secret and browser-binding secret, expiry and use times, and an original account reference when you explicitly link an existing account. Matching an email address alone does not transfer another account's private records.
Email verification uses a configured email delivery provider, currently implemented with Resend, to send a sign-in link to the address you supply. Sign-in email is separate from optional marketing. Necessary browser cookies support verification and sessions; session records retain hashed tokens, account references, creation, last-use, expiry and revocation times. Abuse-prevention counters use keyed identifiers. Expiring or signing out of a session ends access through that session; it does not delete the account or its historical records. Email sign-in remains unavailable until the delivery service is configured; the sign-in page shows the available access method.
Participant invitations and individual rules records
A party leader may enter a named participant's email address to prepare a private invitation for that person. We store the invitation's request and roster position, email, hashed invitation secret, expiry/revocation times and the trip details it covers. The link expires after 48 hours and is shared by the leader. Its secret is read from the URL fragment, removed from the visible address, and temporarily retained in that browser tab to resume after sign-in. Share it only with the intended participant.
When you independently acknowledge rules, we save your account reference, email, participant name, exact acknowledgment statement, trip-detail snapshot, version digest and acceptance time. The internal snapshot includes the named party and applicable property rules. The leader can see completion progress for the current trip details. Your personal history and downloadable copy are restricted to your accepting account and omit other participants' names and email addresses. Later edits can require a new acknowledgment; they do not rewrite your earlier record. This acknowledgment is not a liability waiver, identity verification, booking confirmation or permission to enter. You can view your records at Your rules acknowledgments.
Payment records and private operational review
The current payment integration is for testing; it does not enable real paid hunts. Payment-related records can include the paying and owner account references, named roster, dates and schedule, accepted checkout-detail snapshot, amounts, policy versions, provider references and payment, cancellation, refund and transfer states. Private append-only histories preserve changes to payment amounts, references and statuses, provider charge-review observations, and transfer-recovery attempts, including operator reasons and provider reversal references. That history omits the full roster, checkout agreement text and checkout description; the associated transaction records retain their own snapshots.
Authorized operators can review property contacts, party-leader contact details, historical participant invitation and acknowledgment contacts, requested and payment rosters, dates and limited payment status to identify records potentially affected by an access problem. This information is not included in public hunt discovery. A report or saved payment status does not prove that everyone was contacted, that a refund reached a bank, or that access was granted or revoked.
Account, invitation, acknowledgment and payment history can remain after a link or session expires. Historical records support integrity, support, dispute handling and applicable record obligations. They are not automatically erased by cancelling a request or changing its details. Access, correction and deletion requests require review of the associated records and applicable retention obligations; this page does not promise a fixed deletion date for those records.
Saved hunts on your browser
If you choose Save hunt, this browser stores the public listing identifier and title for up to 50 hunts in local storage. This shortlist is not an account and does not sync to another browser. It remains until you remove the hunts or clear site storage. Anyone using this browser profile may see it. Saving does not hold dates, and titles may change; open the listing for current details.
Parcel-first private owner workspaces
After an eligible five-field property-interest quick start or private response to a hunter request, the continuation holder must choose an exact county bound to the saved state and separately record an owner or authorized-representative assertion before creating a listing. The workspace stores that county/FIPS pair, relationship, assertion version and time, and bounded workflow timestamps. The assertion is a submitted statement—not email, identity, ownership, title, authority, parcel, or hunting-rights verification. Saving it creates no property listing, public inventory, publication consent, booking, payment, agreement, permission, or access right.
The holder may optionally provide one private address, parcel or APN, official-record URL, or other record clue and separately authorize Back40 Pass to prepare a parcel before the hunt details are complete. The authorization expires at the earlier of 30 days or the underlying activation expiry. The owner-facing response never echoes the clue. Successful preparation removes the clue and owner note; cancellation or expiry removes them and any unpromoted staged locator, parcel reference, source, geometry, and operator note. These private fields are excluded from public pages, public maps, analytics, application logs, email copy, and marketplace-event reasons.
A listing is created only after the existing complete hunt-detail payload validates and the active workspace revision wins an atomic promotion. Promotion uses a fresh listing-manager capability, carries the recorded assertion, and may transfer either the private request or a canonical operator-prepared parcel into listing-private records. A transferred parcel is always a draft with empty owner public-boundary consent and no operator verification, and the workspace copy is scrubbed. The owner must still inspect the parcel, separately consent to the exact geometry-and-evidence revision, submit it, and pass operator review before a listing or map can be published.
Private hunter invite links
After a hunter submits a request, Back40 Pass may provide a request-specific link the hunter can choose to share with a possible landowner. The link reveals only the request state, normalized game category, party-size band, and broad timing. It does not reveal the hunter's name, email, phone, location, public area, notes, referral code, or internal request identifier. Anyone who receives or is forwarded the link can view those limited details, so hunters should share it only with people they trust.
The secret portion of the link stays in the browser URL fragment, is removed from the visible address after the page reads it, and is not included in our page or funnel event fields. We store only a one-way hash of the secret and an expiry time. The link expires after 30 days and also becomes unavailable if the underlying hunter request is no longer active. A hunter can ask us at hello@back40pass.com to revoke an issued link. Revocation deletes the stored hash, is permanent for that link, and is not undone by reactivating the request. If a landowner submits a possible property fit through the link, we store an internal relationship between the two private requests so our team can review the possible fit. That submission is not a match, introduction, booking, lease, or hunting permission.
Originating-hunter public listing handoffs
Within the authenticated operator desk, Back40 Pass may connect an active private landowner response to its exact originating hunter request and to a property listing created from that response. The handoff is available only while the response and hunter remain active, the response stage is eligible, their stored state and canonical game match, any stored public-request reference is absent or points to that same hunter, and the listing still has the exact source lineage, matching state and game, and every current public-review, consent, publication, parcel, and availability gate. Removing a public hunter-request card does not by itself delete this otherwise-valid private response relationship.
The prepared handoff contains only the listing's already-public title, broad area, state, game, access type, whole-party daily price, and public URL. The operator addresses it using the originating hunter email already submitted in the private request. It does not add the landowner's name, email, phone, private notes, exact address or location, parcel or APN reference, source evidence, entry, parking, sensitive areas, internal identifiers, or capability secrets. The controls only copy text or open a local mail draft; they do not create a send, delivery, receipt, open, reservation, booking, payment, priority, permission, or access record.
Our private operator report also counts raw demand-linked milestones using that exact current lineage. Responses, listing drafts, and originating-hunter date requests are labeled with their selected report period; active continuations, owner assertions, parcel submissions, parcel verifications, and strict-public listings are labeled as current snapshots. These overlapping counts are not rates. The report returns aggregates, not either party's contact fields, notes, property evidence, or capability secrets.
This policy covers the Back40 Pass founding-list, property-review, and no-payment date-request tools. We’ll update it before paid bookings or materially different data uses begin.
Information we collect
When you join the founding list, start a property review, or request dates on a reviewed property, we collect the information you submit. Depending on the path, that can include your name, email, optional phone number, broad location, hunting preferences, party size, approximate acreage band, property description, desired access dates, whole-party daily price, rules, and notes. We also store the page and privacy-limited campaign parameters that led to the submission, plus any valid referral code.
Private landowner continuation, manager, and browser-return capabilities
When a landowner uses the property-interest quick start or privately answers a hunter request, Back40 Pass can create a short-lived, one-use continuation capability tied to that exact saved interest or response. The continuation may prefill the submitted name, email, state, broad county or area, a supported game category when one was supplied, and a mapped owner or authorized-representative relationship. A co-owner or someone who was unsure about control must instead choose either owner or authorized representative before a full property draft can be saved; Back40 Pass still reviews authority later.
When the API returns an eligible continuation, the success screen validates its same-origin relative path and fragment and keeps it in an in-memory ref—not React-rendered state, an href, a fallback field, analytics, application logs, query parameters, or JavaScript-accessible browser storage. The original submitter may choose Continue, which revalidates the ref-held value and navigates the same tab with only the relative path and fragment, or explicitly choose Copy for their own return. Only Copy reconstructs the absolute same-origin link and writes it to the system clipboard. Anyone who uses the link can continue the draft and receive its manager control, so save a private copy only for your own return; never forward or publish it or save it in a shared or insecure place. The raw capability then appears in the continuation page's URL fragment. That page removes it from the address before the first same-origin request, keeps the captured value in an in-memory ref, and sends it with no referrer. We store a one-way hash, expiry and consumption facts rather than the raw capability in the workflow record. The private continuation page does not use analytics or JavaScript-accessible browser storage, is not indexable, and is served with no-store and no-referrer controls. An invalid, expired, previously used, replayed, or otherwise inactive capability receives the same unavailable response.
After an eligible property-interest quick start—but not a demand-linked private response—Back40 Pass also queues one automatic continuation email to the submitted address. The dispatcher derives a separate private capability only when it claims that exact work. Before it is opened, the raw value exists only in dispatcher memory and the provider message; resolving the link can store that same raw capability in the separately described HttpOnly browser-return cookie. We store its one-way hash, installation time, expiry, first-resolution time, and bounded workflow facts. The emailed capability is usable for up to seven days from preparation, never outlives the original continuation, and shares the same one-draft consumption and source-eligibility gates. Opening it does not verify the email address, identity, ownership, title, authority, or hunting rights, and it does not submit or publish a listing, reserve dates, authorize access, create a booking or agreement, or collect payment. Provider acceptance and delivery are not guaranteed.
For current landowner flows, Back40 Pass may also automatically store one raw return capability—the latest eligible continuation or property manager only—in a host-only cookie with no Domain attribute. It is HttpOnly, Secure, SameSite=Strict, scoped to the exact /api/landowner-resume path, and retained for no more than 30 days; an underlying one-use continuation can expire sooner. Starting a newer eligible flow overwrites the earlier browser return. Anyone using the same browser profile may try to resume that latest flow. A return request sends the cookie only to the same-origin resume API, which revalidates the current database record before returning a 303 response with the existing private route and raw capability in its URL fragment. The destination page immediately scrubs that fragment before its first private API request. An invalid, expired, used, rotated, retired, or otherwise unavailable return is cleared. The raw cookie is unavailable to page JavaScript and is not copied into React state, local or session storage, analytics, application logs, query strings, metadata, referrer data, or public HTML. The property-review page provides an explicit Forget action; stale-link cleanup removes the cookie only when it still matches that exact invalid capability, so it does not erase a newer flow. Copy remains a deliberate backup for return on another browser or device.
Using the continuation or browser return only opens the relevant private flow. It is not email confirmation, property submission for review, publication consent, publication, a listing agreement, a booking, payment, or permission to enter. The separate property-draft email consent remains unchecked until the landowner chooses it. The current full form—whether direct or continuation-linked—uses the same-session parcel-v1 path and can return a same-origin, query-free manager URL whose random secret remains in the fragment. The page navigates with only the relative path and fragment. The manager scrubs the fragment before its first API request and keeps the captured capability in a ref unless the current holder explicitly copies it for their own return. Only that click constructs the full private link and writes it to the system clipboard. Anyone holding it can control or retire the draft, so save a private copy only for your own return; never forward or publish it or save it in a shared or insecure place. An exact unauthorized 404 clears the in-memory capability and requests match-only browser-return cleanup, while a validation conflict or temporary server failure leaves it available for retry. The owner-assertion deadline is seven days from draft creation. If the assertion succeeds in time, that deadline no longer applies and the same manager fragment capability remains active until it is rotated or the draft is retired. This same-session path does not queue or verify confirmation email. The owner or authorized-representative assertion is a submitted statement—not email, identity, ownership, or hunting-rights verification. Mode-omitted client submissions and legacy records may retain email-recipient confirmation.
Property drafts, parcel maps, and no-payment date requests
A landowner property submission remains private. The current same-session path gives its capability holder controls for recording an owner or authorized-representative assertion; that statement proves neither identity, ownership, nor control of hunting rights. Mode-omitted client submissions and legacy records may still let an email recipient confirm only receipt of that legacy private link. The current parcel-v1 full form must submit private parcel evidence before the listing can be submitted for operator review. Back40 Pass still separately reviews authority and every proposed public fact before publication.
The parcel editor uses a pinned local county list to bind a county selection to the listing state. It can link to a state official property-record path with no Back40 Pass referrer. Opening that third-party site can reveal ordinary network and device information to it, but Back40 Pass does not add the draft capability, APN, geometry, contact, or source evidence to the link. For owner-drawn parcel-v1 evidence, a private parcel or APN reference is required. Official-record and parcel-provider sources have their own evidence fields. We store the county/FIPS anchor, canonical Polygon or MultiPolygon geometry, the private source fields, and one-way evidence hashes used to bind later consent and review to the exact revision. We do not publish the owner’s name, email, phone, assertion or authority evidence, private notes, exact address, parcel or APN reference, source URL, provider key, gate, entry point, parking location, or sensitive areas.
Drawing stays in the browser until the landowner explicitly saves or submits it. A local GeoJSON import is read only in that tab; the original file and Feature properties are not uploaded, and only the extracted canonical Polygon or MultiPolygon is included after an explicit save or submit. The private editor does not use analytics, JavaScript-accessible storage, geolocation, or coordinate logging. The separately scoped landowner browser-return cookie does not contain geometry or evidence. Basemap requests do not include the drawn or imported geometry.
After recording the owner assertion, a landowner may separately authorize Back40 Pass to use one private property address, parcel or APN, official-record URL, or other record clue for up to 30 days to prepare an unconsented private parcel draft. We store the selected county, clue type, raw clue, optional owner note, authorization version, and limited workflow timestamps while that request is active. An authenticated operator can see the active clue and owner contact in the private operations queue and use the cited official record or parcel provider to prepare a private draft. The clue cannot be used for preparation after its 30-day expiry. Preparing or cancelling clears the raw clue and owner note immediately; after expiry, the next private owner-status check or authenticated operator queue check clears them before returning status. Preparation retains only bounded workflow facts and one-way geometry and evidence hashes. The clue, note, exact geometry, source evidence, and manager capability are not placed in public pages, maps, analytics, application logs, marketplace event reasons, or preparation email. An operator-prepared draft has no owner publication consent or operator verification and cannot satisfy parcel submission, listing submission, publication, booking, or access gates. The manager capability holder must inspect or edit it and separately apply the existing exact-revision public-boundary consent before submitting it.
Submitting a current parcel revision for review requires a separate checkbox, unchecked by default, authorizing publication of that exact revision’s reviewed boundary and county. Consent does not publish the map by itself. Parcel-v1 consent and operator verification are bound to the exact evidence and geometry hashes. The boundary appears only after operator verification and while the listing still passes the public marketplace gates. A broad view instead uses an approximate point derived from the approved publication. Revising the geometry, county, or evidence resets consent and verification; the landowner can also revoke publication or delete the map. If a published parcel-v1 listing is invalidated by any of those actions, Back40 Pass immediately pauses the listing and removes its public listing, map, and sharing surface until current evidence is submitted and the property passes operator re-review. A public reviewed boundary can identify the hunt footprint, but it is not a survey, title or ownership proof, parcel-provider verification, access route, invitation, permission to enter, or a guarantee of game or legal hunting access.
A hunter date request stores the contact details, requested dates, party size, message, and the server-snapshotted listing price needed for manual review. A date request is not a reservation, booking, lease, payment, or permission. Private property and request-management links use random URL-fragment secrets, remove them from the visible address before the first API request, and store only one-way hashes in their workflow records. Except for the landowner browser-return cookie and explicit property-manager copy action described above, the app keeps raw management secrets in in-memory refs while the page is open. We do not automatically place these secrets in JavaScript-accessible browser storage, analytics, application logs, public HTML, metadata, or query strings.
Real property and date-request workflows can create durable email work for a mode-omitted or legacy listing confirmation, hunter request receipt, private owner date request, or quote-ready notice. Current same-session parcel-v1 drafts do not create listing-confirmation email work. The outbox stores the workflow kind and reference, content and capability versions, one-way recipient-email metadata, idempotency and attempt facts, status timestamps, and limited errors—not a generated body or raw capability. A configured provider receives the current recipient address and message content only after an exact claim; a controlled manual fallback is available only after competing unclaimed automatic work closes. Separate legacy operations records can retain manual-only queued, prepared, marked-sent, skipped, or stale facts. A manual “marked sent” record is an operator attestation, and automatic provider events do not create or change that legacy attestation.
Back40 Pass does not collect card, bank, payout, or tax-identity information through this request-to-book flow. No payment is collected online today. If paid access launches later, we will identify the payment provider and update this policy before collecting payment-related data.
Platform date-hold records
A date request alone does not block dates. If an owner expressly authorizes the exact dates, party size, whole-party land-access subtotal, and conditional platform hold, we store the authorization version and time. If the hunter then starts the hold while every current gate passes, a separate record stores request and listing references, the exact date range, active or released status, database-recorded hold and expiry times, any release time and limited release reason, and bounded mutation facts. An active, unexpired record prevents overlapping Back40 Pass requests and holds from proceeding. An expired or released hold no longer blocks those dates on our platform. These records do not include payment data and do not create permission to enter or hunt.
Private owner date-request decisions
Back40 Pass may prepare a private owner-review link for a submitted date request and, after exact operator authorization, use a configured provider or a controlled manual fallback to send it. The page can show only the hunter-supplied name and a contact-safe note, the listing snapshot and broad public area, requested dates and party size, access-price snapshot, and public listing rules. It does not separately expose contact fields, owner contact information, exact property details, internal database identifiers, attribution fields, or campaign fields. If a hunter note contains an email address, phone number, or another private location detail, the owner page withholds the entire note.
The link uses a dedicated random secret in the URL fragment, removes it from the visible address before the first API request, keeps it only in memory while the page is open, and sends it only to the same-origin owner-decision API with no referrer. We store only a one-way hash of that secret. The private owner page does not use browser storage or analytics, is not indexable, and is served with no-store and no-referrer controls. Anyone holding the active link can choose the owner action, so recipients should not forward it.
An owner can authorize the exact dates, party size, and whole-party land-access subtotal for a conditional 24-hour platform hold or decline the request and may add a private note of up to 500 characters. We store the decision, note, decision time, and required hold-authorization version and time with the request and record a limited owner workflow event without copying the note or secret. The owner can also make a separate optional contact-sharing choice that is unchecked by default. Declining does not record either authorization. Either action invalidates the owner link. The authorization permits only those snapshotted access-price terms and a limited platform hold if the hunter acts while current gates pass; the owner action does not itself start a hold. It is not payment, a final access agreement, permission to enter, or hunting access. Declining ends this request workflow without creating those outcomes.
Optional mutual email introductions
After an owner-authorized access-price snapshot is issued, a hunter can start its 24-hour platform hold whether or not they choose either optional introduction checkbox. If no introduction was requested at hold start and the introduction has not already queued, released, or closed, the holder of the hunter's private request capability may separately request it while that exact hold remains active. The later contact-sharing consent and adult attestation are separate choices and remain unchecked until selected. This later action does not restart or extend the hold, change its dates, expiration, or request status, collect payment, or create a booking or access right. Anyone holding the active private link can use its available actions, including authorizing this limited name-and-email sharing, so do not forward or publish it.
A mutual introduction becomes eligible only while that request's exact hold remains active, the owner separately consented while authorizing the displayed dates, party size, and access subtotal, the hunter separately consented to contact sharing, the hunter separately attested that they are at least 18 and authorized to discuss the request, and all current listing, request, date, delivery, and review gates still pass. Each consent is versioned and limited to one request-specific mutual email introduction; it is not consent to unrelated marketing. An eligible introduction draft may share each side’s name and email address with the other and include the approved broad request facts needed to identify the request, such as the public listing title and area, state, game, dates, party size, access type, price snapshot, and public rules. It does not share either party’s phone number, an exact address or location, parcel or APN information, source evidence, gate or entry details, parking or sensitive areas, private notes or message text, capability secrets, internal identifiers, or referral and campaign fields. Authorized Back40 Pass operators already process submitted names and email addresses in the separate private listing, request, and delivery workflows; introduction release is the additional authorization to assemble those contacts into one mutual To/Cc draft, not the operator’s first access to them.
The introduction record stores consent choices, consent versions, workflow status, limited timestamps, and requires the request's current active hold; it does not copy names, email addresses, message bodies, phone numbers, property evidence, or capability secrets. Awaiting, queued, released, skipped, stale, and cancelled states move only forward, so a closed or released introduction cannot be restarted through the hunter action. Unreleased introduction work becomes stale or is cancelled when the underlying request, hold, or listing no longer passes its gates. During the founding launch, an operator must trigger an exact server recheck before Back40 Pass irreversibly authorizes and assembles the request-specific mutual draft. Only after that release may a configured provider receive the separately consented names and email addresses as one To recipient and one Cc recipient with the current allowlisted draft content, or an operator may use the controlled manual fallback. The audited release fact is not proof of dispatch, provider acceptance, recipient-server delivery, receipt, opening, reading, or reply. A later withdrawal, expiry, or listing change cannot recall a draft already released. Release is not proof of a match, paid booking, final access agreement, payment, permission to enter, or hunting access.
First-party attribution and measurement
If you arrive through a referral or campaign link, the site may store that first-touch source and referral code in your browser. It expires 30 days after it is first captured; later visits do not extend that expiry. When the current page URL contains a valid referral code, we may record a referral landing. A later direct visit that only uses stored attribution does not create another referral-landing event. After you successfully join the founding list, the site may separately store your own referral code on that device for 30 days so a request-building tool can attach it to a link you choose to share.
After an eligible landowner records private property interest, the success screen may separately show a reusable public landowner signup link that the landowner can choose to share. That public link contains only a state, member referral code, and fixed campaign labels. It does not contain the landowner's name, contact details, property area, relationship answer, private continuation, manager capability, or draft-control secret. Sharing or opening it does not continue or control the original interest and does not create a property interest or listing for the recipient.
We also use a random identifier that lasts only for the current browser tab to count landing views, page views, conversion-link clicks, form starts, completed requests, and coarse tool steps such as start, official-resource open, print, copy, share, or marketplace handoff. We hash that temporary identifier before storing an event. Public map interactions may use only these existing coarse event types. We do not put map coordinates, bounding boxes, zoom level, geometry, county, parcel or APN references, listing identifiers, or capability tokens in event records. The private parcel editor and private management route do not run analytics or store a tracking identifier. Other event records can include the site path, broad hunter or landowner role, state, and campaign labels, but not your email, county, ZIP, phone number, property details, request draft, or notes. Back40 Pass honors Global Privacy Control and browser Do Not Track for this session and referral-growth measurement. You can clear stored attribution and referral codes through your browser controls.
Public map provider
When you open the public map or private parcel editor, your browser requests the Liberty basemap style, tiles, sprites, and map labels from OpenFreeMap. Those requests can reveal ordinary network and device information such as your IP address and user agent, the requested map resources, and the tile area and zoom level you viewed. Back40 Pass sets those requests and map-page links to send no Back40 Pass page referrer. We do not send your drawn geometry, county, parcel or APN reference, source evidence, owner contact details, listing identifier, or private capability token to OpenFreeMap with a basemap request. OpenFreeMap’s own policies apply to its handling of those requests. The basemap is built with OpenMapTiles and OpenStreetMap data and carries their required attribution.
Permission request, courtesy-record, and publisher tools
The hunting-permission request builder and printable courtesy-record tool run in your browser. Your entries are kept in memory in the current tab and are not transmitted to Back40 Pass when you copy a request, print a courtesy record, or share the builder. Printing uses your browser’s print or PDF controls. Copying places the generated request text on your device clipboard. A builder link you choose to share can include state, game, party size, campaign labels, and your unexpired referral code, but not your name, contact, requested area, timing, selected details, property identifier, rules, or draft text. If you choose to start a marketplace request, the destination URL can include state, game, and party size; information submitted through the marketplace form is handled as described above.
The permission publisher kit generates a public state resource link, newsletter copy, share copy, and passive embed code from a state, theme, and optional organization slug. If supplied, that exact slug is public in the generated URL and embed markup and can appear in first-party attribution after a reader follows a generated link. Do not enter a person’s name, email address, page URL, or another private identifier as the slug. Beyond the temporary session identifier, site path, and campaign labels described above, builder-specific telemetry fields are limited to state and action placement. It can record one builder-start after you interact with it; it records a copy or share placement only after an automatic copy or native share completes successfully. A cancellation or failed copy is not recorded as a successful action. Those events do not prove that material was pasted, published, sent, delivered, opened, read, or clicked. The embedded card itself does not record a host-page impression or inspect the host page. A privacy-limited first-party landing can be measured only after a reader chooses a tagged Back40 Pass link, subject to the browser privacy controls described above.
The official hunting-access publisher kit uses the same limited model for a state resource link, newsletter copy, share copy, and passive embed. Its optional exact organization slug is public in generated URLs and markup and can label a later first-party landing; never use a personal or private identifier. Common session, path, state, campaign, and action-placement telemetry can record a builder start and only a successfully completed automatic copy or native share. It does not establish publication, installation, delivery, reading, an embed impression, or a resulting visit. The embedded card does not inspect the host page or record a host-page impression.
The landowner access-options publisher kit uses that same public-slug and successful-action-only model for a state-specific official-program explainer, newsletter copy, share copy, and passive embed. Its copy distinguishes a verified access program, related assistance only, and no identified statewide program; it does not claim a local option, available property, listing, booking, payment, lease, permission, endorsement, or partnership. The card does not inspect its host page or record a host-page impression. A tagged reader may choose to record private owner interest or continue into the existing listing workflow, where the submission, parcel-review, consent, moderation, and publication controls described elsewhere in this policy still apply.
The reviewed hunter-demand publisher kit can filter by one state and optional controlled game category. Its passive embed rechecks the same current-consent, moderation, active-status, supported-field, and non-null future-expiry gates used by the public request board, then displays at most three briefs. Public output is limited to a generated request ID, state, broad area, game, party-size band, timing, and publication month. It never receives a hunter’s identity, contact details, exact search area, raw location, notes, member identifier, moderation notes, source attribution, or private capability. A confirmed empty result remains distinct from a query failure. The optional organization slug and limited builder telemetry follow the same public-slug, successful-action-only, no-host-impression model described above.
Private publisher activation desk
Back40 Pass maintains a private, authenticated operations list with one organization-level publisher candidate per state. It stores the organization name, public domain, official public contact-source URL, public source-evidence URL, a non-personal public attribution slug, broad audience and organization categories, recommended public asset, bounded lifecycle timestamps, and any manually verified public placement URL. A contact source may be the organization's contact form, organization page, or another official page that publishes its general channel. It does not store a contact person, personal email address, phone number, private message, or scraped profile.
Every researched organization starts as an unreviewed candidate. An operator must separately attest that the official source pages were reviewed before the record becomes ready, record contact only after a human actually submits one transparent inquiry through the organization's public channel, and record a placement only after opening an organization-controlled HTTPS page and seeing the Back40 Pass link or embed live at that time. That timestamp is a historical verification, not continuous uptime monitoring; an operator must reopen the recorded page before claiming it remains live. Copying material, opening a contact source, tagged traffic, or an organization's public existence is not treated as contact, delivery, acceptance, endorsement, partnership, or publication. Declined, do-not-contact, and invalid outcomes are retained so those boundaries can be honored.
The desk can report raw, privacy-limited first-party measurements carrying the exact public organization slug, source, medium, campaign, role, state, and expected Back40 Pass path. Landing figures are distinct sessions on that exact expected path. Form-start, request-created, and tool-start figures are distinct sessions with the same attribution, role, and state labels but are not restricted to one path. Linked landowner responses are eligible row counts, not sessions. Owner-interest records, listing drafts, and parcel-review submissions are exact attributed durable row counts, not sessions, within the stated report period. Strictly eligible live listings are a current snapshot and must still pass every publication, moderation, owner-consent, parcel-review, availability, and status gate. The attribution labels are stored/current first-touch labels. These overlapping figures are not host-page impressions, click cohorts, sends, deliveries, opens, placement proof, conversion rates, matches, bookings, or payments. Global Privacy Control, Do Not Track, an earlier first touch, and blocked storage can suppress later tagged visits and durable-row attribution.
Hunting lease price calculator
The hunting lease price calculator runs in your browser. Your local area, comparable prices, acreage, costs, target return, package notes, and test price stay in memory in the current tab and are not sent to Back40 Pass. Copying or printing uses your device. A link you choose to share can include state, game, access format, and campaign labels, but never the worksheet amounts or local area. Coarse tool events can record start, copy, print, share, or marketplace handoff plus state; they do not include the worksheet values.
Optional public hunter requests
A hunter can separately ask Back40 Pass to review a privacy-safe request for the public hunter-request board. This choice is optional, unchecked by default, and separate from the required checkbox allowing Back40 Pass to email about the submitted request, moderation, and relevant property availability. The form shows the public fields before submission. If approved, a card may show only the hunter-supplied broad county or region, state, normalized game category, party-size band, broad timing, and a broad publication month. It does not show the hunter’s name, email, phone, private location or ZIP, notes, access-format preference, referral data, member or database identifier, or exact submission time. If a landowner responds from a card, we may store that card’s system-generated public share ID with the private property intake so our team can identify the brief being answered.
Public requests are reviewed before publication and may be declined, hidden, or removed for safety, privacy, duplication, age, accuracy, or abuse concerns. A published request is publicly accessible and can be copied, shared, indexed, or captured by others. To withdraw or remove one, email hello@back40pass.com; we may need to verify the requester. Removing a card from the board does not automatically delete the underlying private founding-list record.
Hunter Demand Watch alerts
A landowner can optionally provide an email address, one U.S. state, either any reviewed game category or one exact public game category, and an unchecked watch-only consent choice. We keep the email private and do not publish it on a hunter request or create a land listing, property offer, lease, match, or hunting permission. A new watch remains pending until the email recipient uses a private confirmation link. That consent covers only the requested demand-watch alerts, not unrelated marketing.
Back40 Pass reviews each alert's eligibility and can use a configured email provider or a controlled manual fallback. A confirmed watch is eligible only for new, active public hunter-request briefs that passed the current publication, consent, moderation, status, expiry, state, and mapped-game checks. We do not use private, pending, declined, withdrawn, removed, expired, unmoderated, or unmapped requests for a demand-watch alert.
Private confirmation, management, and unsubscribe links place a random secret in the browser URL fragment. The page removes that fragment from the visible address before checking the watch, and we store only a one-way hash of the secret. Each alert uses a separate one-use unsubscribe capability. Unsubscribing closes this watch and its unclaimed email work; it does not globally suppress unrelated listing confirmations, booking receipts, or other requested messages sent to the same address. A provider-claimed message is already in flight and may complete after unsubscribe. We do not guarantee confirmation or alert delivery, timing, a request, response, match, introduction, booking, lease, or permission.
Hunt Availability Watch alerts
A hunter can optionally provide an email address, one required U.S. state, either any listed game category or one exact canonical marketplace category, any future dates or one exact date range of up to 14 days, an optional party size, optional whole-party minimum and maximum daily prices, an optional access type, an optional legal method, and an unchecked watch-only consent choice. A search-to-watch handoff can place the unassociated search criteria—but never the hunter's email, a saved watch identifier, or a private capability—in the watch page URL and rendered prefilled form. Anyone given that URL can see those prefill values. After submission, we keep the email-to-saved-criteria association private: it is not shown to landowners or placed on public hunt pages, public metadata, or analytics. A public count returns only the number of reviewed live listings matching the submitted criteria. A new watch remains pending until the recipient uses a private confirmation link. That consent covers only the requested hunt-availability alerts, not unrelated marketing.
A current confirmed watch is eligible only for real listings published or republished after the watch was created and still passing every saved criterion plus the current public-review, consent, moderation, status, and viable-date gates. An exact-date watch automatically stops matching after its saved end date. Legacy watches created under the earlier criteria version retain their private state-and-game-only behavior; they are not silently rewritten as exact-search watches. Fictional example hunt cards never trigger counts or alerts. Eligible confirmation and alert work can use a configured email provider or a controlled manual fallback. Queueing, preparation, provider acceptance, or a manual attestation does not by itself prove recipient delivery, opening, reading, a reply, or timing.
Private confirmation, management, and unsubscribe links keep a random secret in the browser URL fragment and remove the fragment and any query from the visible address before the first API request. The private page can show the saved criteria only after same-origin authorization with that secret. We store only a one-way hash of each confirmation, management, or per-alert unsubscribe secret. Raw secrets and the private email-to-criteria association are not stored in analytics, browser storage, public HTML, metadata, or query strings; this is separate from the visible, unassociated search-prefill criteria described above. Global Privacy Control and Do Not Track suppress submitted campaign dimensions and the temporary analytics identifier for this watch. Unsubscribing closes this watch's unclaimed work only, does not suppress unrelated requested email at the same address, and cannot recall a provider-claimed message already in flight.
Email queue and provider records
We create durable work independently of provider configuration for eligible property-interest quick-start continuations, mode-omitted or legacy listing confirmations, hunter request receipts, private owner date requests, quote-ready notices, demand-watch confirmations and alerts, availability-watch confirmations and alerts, and separately authorized mutual introductions. The quick-start message is separate pre-draft work and does not create an email-verification fact. Current same-session property drafts do not create listing-confirmation email work or an email-verification fact. The queue stores a workflow kind and reference, content and capability versions, one-way recipient-email metadata, an idempotency key, attempt and retry facts, exact status timestamps, limited error codes, and provider-event metadata. It does not persist the generated message body or raw capability. A provider receives the current recipient address and message content only after the app wins an exact claim immediately before dispatch; a mutual introduction also requires exact prior operator release before its To/Cc addresses and allowlisted content can be disclosed. If no automatic attempt is active, an authorized operator may use a controlled manual fallback only after the app atomically closes competing unclaimed work. For a watch confirmation, the confirmation-link-prepared time means its private capability and link were prepared through either the provider path or the manual fallback; the separate confirmation-marked-sent time remains a manual operator attestation only.
“Queued” and “retry waiting” do not mean sent. “Claimed” means an irreversible provider attempt is in flight. “Provider accepted” means the provider accepted the API request, not recipient-server delivery. “Delivered” means a recipient mail server accepted the message; it is not proof of inbox placement, recipient receipt, opening, reading, reply, match, booking, payment, agreement, permission to enter, or hunting access. Outcomes can differ for the To and Cc recipients, so a singular outbox status does not establish the same outcome for both. We do not treat opening or reading as an observable workflow outcome. If the original 24-hour idempotency window expires without a reliable terminal result, we stop retrying and report the provider outcome as unknown. Verified provider hard bounces, complaints, or provider suppressions can suppress other provider email to that address; a watch-specific unsubscribe does not.
Fishing submissions
When you request fishing access or offer water for review, we privately store your name, email, role, general area, state, species, water and access preferences, dates, group size, optional price or budget, property name and authority statement if supplied, rules, consent, submission identifier, review status and timestamp. Authorized operators use these records to discuss your submission and assess property fit or demand. They are not public listings, verified ownership records, bookings or general marketing subscriptions. Do not include exact addresses, identity documents or gate codes.
Product feedback
If you submit feedback, we store your selected role, reason, description, entry point, submission identifier, review status and timestamp privately. Email is optional and stored only when you agree to contact about your feedback or a usability session. This is not marketing consent. Feedback is available to authorized operators; it is not published as a review or counted as a verified customer outcome.
Search and referral measurement
For visitors who allow existing activity tracking, we classify recognized search, AI and social referring sites using only the referrer hostname. We do not save the referrer’s path, query, or unknown hostname. Missing referrers are labeled direct or unknown. First-touch campaign or inferred source information expires after 30 days and is kept separate from later internal navigation. Inferred sources are estimates, not verified people or proof of an AI citation. Permission drafts, checklist selections and trip-cost amounts stay in your browser tab; copied documents include the details you choose to copy.
How we use it
We use the information to respond to you, assess marketplace demand and property fit, recruit supply by area, send launch or availability updates you requested, prepare a request-specific mutual email introduction when both sides separately authorize it and all current gates pass, prevent abuse, improve the site, understand which pages and campaigns produce useful requests, and prepare Back40 Pass operations. We may record privacy-limited referral landings from current referral links and share attempts using a referral code, target role, state, channel, and site path; those events do not include your email, county, ZIP, phone number, property details, draft request text, or notes.
Sharing
We do not sell personal information. We may use service providers that help operate the site, database, email, analytics, maps, or future marketplace. We may disclose information when required by law or to protect people, property, or the service. We do not publish a landowner’s exact property address, parcel or APN reference, source evidence, entry point, or private contact details. We publish a reviewed parcel boundary and county only through the landowner’s separate parcel-map consent and operator-verification process described above. Hunter request details are published only through their separate optional review choice. We share each party’s name and email with the other only through the separately consented, request-specific introduction process described above.
Immutable price-offer evidence
If an operator issues a price record for a no-payment date request, we store its public identifier, version, exact bounded price/hold request and public-listing snapshots, whole-party access subtotal, currency, $0 due-now amount, blocked-checkout statuses, owner hold-scope digest, canonical price/hold snapshot digest, and separate issuance mutation and timestamps. Separate append-only acknowledgement rows store the role, acknowledgement version and context, acknowledged digest, mutation identifier, and time. The owner row is derived from the earlier exact price-and-hold authorization; a hunter row exists only after the private request holder affirmatively acknowledges the canonical price/hold snapshot digest to start the platform hold. These records do not verify identity or authority and are not signatures, contract acceptances, orders, bookings, payments, or access grants.
Checkout preparation records
If an eligible hunter acknowledgement starts a platform hold, we may store a private checkout-preparation record tied to the request and source price evidence. It contains a record identifier, version and digest; its open or closed lifecycle and bounded close reason; currency, access subtotal and $0 due-now amount; blocked, not-collected, not-configured, not-determined, unavailable and not-granted readiness statuses; and its opened, hold-expiry and optional close timestamps. It does not contain card, bank, payout or tax-identity data, a signature, accepted agreement text, a payment-provider object, an authorization to charge, or an access credential.
The private request manager may display this record to the originating signed-in hunter or active private-link holder as read-only internal preparation. Current confirmed property owners can respond to their requests through their account. Revoking a private link does not remove authorized account access; request closure and changes of ownership still restrict actions. We do not publish it on hunt pages or expose it through public metadata or structured data. It is not an agreement, order, acceptance, checkout, payment, booking, reservation, property-access grant, or hunting permission. Legacy requests may have no checkout-preparation record.
Retention and security
We keep founding-list information while it is useful for the launch, relationship, legal obligations, and abuse prevention. Immutable price-offer and role-acknowledgement evidence is retained as a historical workflow record while needed for record integrity, dispute handling, legal obligations, or abuse prevention; later request-state changes do not rewrite it. Privacy-limited funnel and referral-growth events become eligible for deletion after 180 days and may then be kept only in aggregated form. Browser-stored first-touch attribution and returning-member referral codes expire after 30 days as described above. We use reasonable safeguards, but no online system is guaranteed secure.
Your choices
You can unsubscribe from marketing updates using the link in a message. To request access, correction, or deletion of your personal information, including account, property, request or participant records, email hello@back40pass.com. We may need to verify the request and assess applicable retention obligations. Correcting current information does not silently rewrite historical acknowledgments or payment evidence.
Children
The founding list is intended for adults who can enter agreements about hunting access or property. It is not directed to children under 13.
Contact
Questions about this policy can be sent to hello@back40pass.com.