Access and deletion

Who can see whatCopy Anchor Link

• Members see only the sites and reports their role allows. A site they cannot access does not exist for them: the API answers 404.
• API keys see only what their permissions and sites allow; see Permissions.
• Some data needs sessions:read. Sessions themselves, report filters on visitor or user ids, query strings, host names, a ref property or an error's message, stack or file, the values of the checkout event's ref, and buyers' emails are available only to people and keys that can read sessions. Viewers and above have it; a share link only if it includes sessions.
• Share links give read-only access to one site's dashboard, with an optional expiry. They include sessions, users or replays only if the person who creates them chooses so (and holds those permissions), and they can be revoked at any time.
• A public dashboard (Site settings → Privacy & identity → Make the dashboard public) shows traffic statistics to anyone with its link, never sessions, users or replays.

How secrets are kept:

Erasing a user's dataCopy Anchor Link

On a user's page in the Users report, Delete user data (editors and above) erases that user's data on that site in a background job. The same erasure is available over the API with the users:delete permission (reference):

curl -X DELETE -H "Authorization: Bearer $PILOTFOX_API_KEY" \
  https://pilotfox.app/api/v1/sites/SITE_ID/users/u_8f3k2

{ "data": { "jobId": "a0fddee9-d803-42c7-8516-cc38f7ea2ee6" } }

The answer is 202 Accepted as soon as the job is queued, whether or not the user exists, so it reveals nothing. The job then erases:

• It is one site's data: erase the user on each site where you identified them.
• Anonymous visits that were never linked to the user (on a device where identify never ran) cannot be found and stay.
• Deleted rows disappear from every report at once; they leave the database's files when its storage next merges them.
• The job runs again 1 hour later for rows that were still on their way. While an import of the site is waiting or running, it also runs again every 10 minutes until none is (for up to 8 hours), so rows an import brings back are erased too.
• The identity links go in the first run, but the job remembers which visitors it erased until its last run, so the later runs also erase anonymous visits of the linked visitors that arrive late, even if someone else has signed in on that device since.
• Erasing does not block anyone: if the person keeps using your site and you identify them again, new data is recorded.

Deleting a siteCopy Anchor Link

An owner or admin deletes a site in Site settings → Danger zone, by typing its domain to confirm, or over the API with the site:delete permission (reference):

curl -X DELETE -H "Authorization: Bearer $PILOTFOX_API_KEY" https://pilotfox.app/api/v1/sites/SITE_ID

{ "data": { "deleted": true, "jobId": "…" } }

• The answer is 202 Accepted. The site stops at once: its script settings, events and recordings are refused from then on (404).
• A background job starting a minute later erases all of its events, bot requests, session recordings, identity links, user profiles, imports, payments and subscriptions, payment-provider connections, Search Console data, goals, funnels, segments, annotations, share links, affiliates and settings, and runs again an hour later for anything that arrived late.
• This cannot be undone.

Deleting an organization deletes all of its sites the same way.

Deleting an accountCopy Anchor Link

Account → Delete account deletes the signed-in person's own account. It first shows what goes with it, from GET /api/v1/me/deletion (reference; a signed-in session only):

• Gone with the account: its sign-in methods, two-factor settings, sessions, email report subscriptions, new-sale email choices, MCP connections and private segments.
• Kept, no longer linked to the person: annotations, public segments, goals, funnels, sites, imports and payment-provider connections they created in organizations that stay. API keys belong to their organization and stay too. A Slack or Discord new-sale webhook they connected stops sending until someone who can read the site's revenue sets it up again.
• Confirmation: the account's password, or for an account without one (Google, GitHub or emailed codes) a sign-in in the last 10 minutes; the web app also asks for the email address typed out. A session an administrator opened as the person (impersonation) can never delete the account, and neither can the instance's last system admin.
• The browser is signed out, and the account's address gets an email saying the account was deleted. This cannot be undone; backups holding the data are deleted when they expire.

A system admin who removes a user (POST /api/auth/admin/remove-user) gets the same rules: a user who is the only owner of an organization with other members is refused, and the organizations the user is the only member of are deleted with them.

Exporting dataCopy Anchor Link

Site settings → Import & export downloads a site's raw events as JSON Lines (one JSON object per line), for up to 400 days at a time. The same export is available over the API (reference). It needs exports:read and sessions:read (the editor role), because each row carries visitor ids, user ids and coordinates:

curl -H "Authorization: Bearer $PILOTFOX_API_KEY" \
  "https://pilotfox.app/api/v1/sites/SITE_ID/export?format=jsonl&start=2026-09-01&end=2026-09-30" \
  -o events.jsonl

• Each line is one event with its stored fields (see What is stored), in no particular order. The format is the one Import & export reads back.
• A window (start and end, or last) is required: all=true is refused, and so is a window longer than 400 days.
• Identity links, user profiles, session recordings and payments are not exported.
• By default one export of an organization's sites runs at a time; another one meanwhile is answered 429.
• The file has no end marker: if the transfer breaks, treat the export as incomplete and run it again.