Privacy Policy

Effective date: November 3, 2026  ·  Last updated: November 3, 2026

This policy describes how Zhiva ("we," "our," or "the app") handles information when you use our iOS application. We are committed to keeping your pet's health data private.


1. What We Collect and Why

1.1 Diagnostic and Analytics Data

Zhiva collects pseudonymous diagnostic events, linked to your account identifier, to help us understand how the app is performing and identify problems. These events include:

These events record that something happened and when — they do not carry your pet's records or the text of your entries.

Purpose: App functionality and product analytics. This data is used solely to improve Zhiva. It is not sold and is not used for third-party advertising.

You can turn off the events the app sends at any time: Settings → Send diagnostic data. With the setting off, the app stops sending everything it reports itself, and makes no network request to send it: crash and performance reports, app error events, the sign-up, onboarding, first-pet, first-record and paywall steps, and the wallet-pass and vet-summary events. The setting does not reach our server, so it does not stop the events the server records for itself while it handles your requests: completing or failing a document scan, starting and ending a walk, and revoking a share link. Those rows carry your account identifier like the rest.

1.2 Account Information

When you create a Zhiva account or sign in — including with Sign in with Apple — we collect your email address and use it to sign you in. Each account is also assigned a random UUID (owner_id), which is the key used to store your records and to link the diagnostic events described above to your account. Your email and account identifier are used to operate the app; they are not sold and are not shared with advertising networks.

Sign in with Apple. If you sign in with Apple, Zhiva asks Apple for your name and your email address. Apple gives us either your real email address or one of Apple's private-relay forwarding addresses, depending on what you choose in Apple's sign-in sheet. If Apple provides your name, we use it once to fill in the display name on your profile — Apple only ever sends the name on your first sign-in.

1.3 Location

If you start a walk, Zhiva collects your precise location while the walk is active to measure distance and record your route. Walk routes are uploaded to and stored in your Zhiva account. Once a walk has ended, its route coordinates are automatically cleared 90 days later; the walk's distance, pace and times are kept so your pet's activity history stays intact. Zhiva stores your precise location only for walks you start.

Pavement safety. When you open a walk, Zhiva reads your device's current location, if you have allowed location access, to work out pavement safety for the walk screen. Zhiva asks for location access only on the walk screen, after you tap Continue. It sends that location to Apple's WeatherKit service to get the current weather there. That location is not sent to Zhiva's servers and is not stored in your account. Apple says WeatherKit uses location information only to provide weather forecasts and does not associate it with any personally identifiable information. Zhiva's widget does not show weather.

Supabase's request log also records an approximate location worked out from your IP address; see §1.6. Zhiva never uses your location for advertising or to track you.

1.4 Profile and Contact Information

Your profile has optional fields you may fill in. All of them are optional, all are entered by you, and none is collected automatically:

These are stored in your account and used to fill in documents you generate, such as a PDF record summary. They are not sold and are not shared with advertising networks. You can edit or clear them at any time in Settings → Profile.

1.5 Your Pets' Records and Content

The content you create in Zhiva is stored in your account:

Some of this content leaves your account if you choose to create a share link for a pet — see §3.

1.6 Your IP Address and Request Details

When the app talks to Zhiva's servers — for example to sign you in, or to load and save your records — each request passes through Supabase and the infrastructure providers it uses (see §6). Supabase keeps its own log of those requests, outside your account. For each request, Supabase's request log records:

Zhiva can read this log through Supabase's dashboard and tools. Supabase keeps the log for a period it sets. When we checked on September 15, 2026, entries from about the past 90 days could still be retrieved, longer than the 7 days Supabase's pricing page lists for our plan. Deleting your account does not remove entries already in the log; they stay until that period ends. The same log records visits to share pages, though what it holds for them is different; see §3.2.

Sign-in log. Supabase also keeps a separate log of account activity, such as creating an account, signing in, renewing or ending a session, and deleting an account. Its entries about that activity record your email address and account identifier, and many also record your IP address or user-agent string. Zhiva can read that log too. Supabase keeps it for a period it sets, and deleting your account does not remove entries already in it. Zhiva never uses the information in either log for advertising or to track you.

2. AI Processing of Your Documents and Entries

Several Zhiva features work by sending part of your content to Anthropic PBC ("Anthropic"), the company behind Claude, which reads it and returns a structured result. Anthropic processes this content on our instructions to deliver the feature you asked for. It is not an advertising network, and we do not sell your content to Anthropic or to anyone else.

Zhiva asks before any of these features sends anything, in two separate questions: one for document scans (§2.1), and one, called AI features, for voice logs, follow-up questions and insights (§2.2 and §2.3). Your choices are described in §2.5.

2.1 Document scans

When you scan a document, Zhiva sends the page images and the text recognised on them to Anthropic. That includes anything printed on the page — for example the clinic's name, and your own name or address where the document shows them. The images are sent as captured; we do not filter what is printed in the pixels, and we would rather tell you that than imply a filter that does not exist.

This only happens after you accept the consent step Zhiva shows you before your first scan. The page image is saved to your pet's vault before the reading so you can open it later; if you cancel the scan instead of saving it, we delete it.

2.2 Voice logs

Speech is transcribed on your device. Zhiva sends the resulting text to Anthropic to turn it into a structured entry, together with the names and species of your pets (and the random identifiers Zhiva uses for them) so it can tell which pet you mean, and your current local time, so it can tell what "yesterday" means. To work that out, your phone sends its time zone to our server; Anthropic receives the time and its offset from UTC, not the name of the zone. Your audio never leaves your device — Zhiva uses on-device recognition only and does not fall back to a server, and no recording is kept. This happens only once you have turned on AI features (§2.5).

2.3 Insights and follow-up questions

For a proactive insight, we send a small set of figures derived from what you have logged — for example a weight trend, an event count, or an interval between entries. No free text and no pet name is included.

When you ask a follow-up question about an insight, we also send your pet's species and breed, the types, dates and severity of recent entries, recent weight and temperature readings, the names, doses and dates of active medications, and the question you typed. The free-text notes on your entries are not sent.

Both happen only once you have turned on AI features (§2.5). Zhiva does not write proactive insights for an account with AI features off.

2.4 What Anthropic does with it

Anthropic deletes what we send within 30 days, and does not use it to train their models.

2.5 If you would rather not

Document scans. You can decline at the consent step before your first scan. If you decline, nothing is sent for reading: your document is still saved to your pet's vault as an attachment you can open and read at any time, and you can still type in any values you want tracked. Only the automatic reading is off. Your answer is remembered on that device, and you can change it in Settings → Notifications & Privacy → Automatic document reading.

Voice logs, follow-up questions and insights. Zhiva asks before your first voice log or follow-up question, and sends nothing for these features until you turn on AI features. Your answer is stored in your Zhiva account, with the time you gave it, so it applies on any device you sign in on; you can change it at any time in Settings → Notifications & Privacy → AI features. With AI features off, voice logs and follow-up questions are unavailable and Zhiva stops writing insights for you, but typing an entry still works and never goes to Anthropic. Turning AI features off takes effect on your device straight away and on your account as soon as the app next reaches Zhiva's servers. It stops what is sent from then on; it does not recall anything already sent (see §2.4).

Deleting your account removes your content — see §7.

3. Sharing a Pet's Record by Link

Zhiva lets you create a share link for one of your pets — a web address you can send to a vet, a sitter, or anyone else. This is the one feature that publishes your pet's information on a public web page, outside your account, so it is set out here in full.

3.1 What the page shows

Opening a share link renders a read-only page for that one pet, assembled at that moment from the records described in §1.5. Every page shows this summary:

The What's Included section of the share screen has three switches. Each one that is on when you create the link adds more to the page:

All three switches start out on, so a new link includes all three unless you switch one off. Changing the switches does not change a link you have already created. A link created before September 8, 2026 shows only the summary, whatever its switches were set to.

The page carries nothing else from your account, apart from the identifiers in the photo's link described in §3.4. It does not carry your name, email address or any other profile or contact field from §1.4; your other pets; the contents of the documents you have scanned, beyond the title and date of a scan's visit described above; or any walk, route or location data.

3.2 Who can see it

A share link ends in a random 26-character code, and that code is the only thing protecting the page. There is no sign-in and no password. Anyone holding the link can open it — not only the person you sent it to, but anyone they forward it to, and anyone who later reads the link out of a message, an email, or a browser history. Treat a share link as a copy of the record that you have handed out, not as an invitation to one named person.

The page is served at an address of the form https://zhiva.app/s/…, where the last part is the code. The zhiva.app website runs on Cloudflare's network (see §6), and a small program of ours there receives the request and passes it on to Supabase, which builds the page. Cloudflare therefore receives the full address, including the code, the visitor's IP address, and everything else their browser sends with the request, such as its user-agent string. Our program passes on the link code, and three things about the request itself: that it wants HTML, the visitor's IP address, and a shared secret proving the request came through our own page. It does not pass on the browser's user-agent string, any cookie it sent, or any other header it arrived with — with one exception: a diagnostic header we use to trace our own test requests is passed on whenever a request carries it, whoever sent it.

This address is new. A link created before this change keeps the longer Supabase address it was issued with, and is not redirected to the new one; it still opens the same page, served by Supabase without passing through our program on Cloudflare. Where that changes what is logged, it is noted below.

Every time the page is opened, Zhiva counts the view and records when it was last opened, and shows you both on the share screen.

Each request for the page is also recorded in three separate logs, which hold different things and are kept for different lengths of time: our own log line, Supabase's request log, and the line our program on Cloudflare writes.

Our log line. To keep the public address from being abused, the page's own code writes a line for each request. It holds a random identifier for the request, the first four characters of the link code, the visitor's IP address truncated to its first three octets — for example 203.0.113.0/24 — and the outcome, such as page shown, link expired, or not found. If the visitor connects over IPv6, our log line holds only the word ipv6 in place of the address. When the page is shown, our log line also notes which sections it included and how long the server took to gather their contents. The server separately uses the visitor's full IP address to limit how many requests one address can make per minute; it holds that count only in the server's memory, and the full address does not go into our log line. The visitor's address now reaches that code in the header our program on Cloudflare passes on, so it is still the visitor's own address that is truncated and counted; alongside each request the code writes one further short line, holding only the request identifier and whether the request arrived that way.

Supabase's request log. Supabase, which runs the server that builds the page (see §6), keeps its own log of the requests that reach that server, apart from our log line. For a page opened at a zhiva.app address, the request that reaches Supabase is the one our program on Cloudflare makes, not the one the visitor's browser makes. That log still holds the full link, including the code. But the IP address it records for the request, and the approximate location worked out from it, are those of the Cloudflare machine our program ran on, not the visitor's; and it holds no details of the visitor's browser, because our program does not pass them on. The visitor's full IP address is still sent to Supabase, in the header described above; whether Supabase's own log keeps a copy of that header is not something we can see. For a link opened at its older Supabase address, that log holds the visitor's own full IP address, the approximate location worked out from it — city, region, postal code, country, time zone, and the name of the network they connect through — and details of their browser and connection, such as its user-agent string, as it did before this change. Zhiva can read this log too, through Supabase's dashboard and tools. Our log line is also stored in Supabase's logging system, separately from Supabase's request log. Supabase keeps both for a period it sets. When we checked on September 15, 2026, entries from about the past 90 days could still be retrieved, longer than the 7 days Supabase's pricing page lists for our plan; see Supabase's documentation on logs. Revoking a link, or deleting the pet or your account, does not remove entries already in either log; they stay until that period ends.

Our line on Cloudflare. Our program on Cloudflare writes a line of its own for each request it handles. It holds a random identifier for the request, the outcome, how long the request took, and whether the visitor's IP address was present — not the link code, and not the address itself. We do not store these lines, and we have not turned on the Cloudflare feature that would: they can be read only by watching them stream past as they are written, and are gone once that stops. What Cloudflare keeps about a request for its own purposes is covered by its privacy policy, linked in §6.

If the pet has a photo, the page includes the temporary link to it described in §3.4. That link points straight at Zhiva's Supabase storage, so the visitor's browser fetches the photo from Supabase itself, without passing through our program on Cloudflare. Whenever the photo is fetched, the request is recorded in Supabase's request log, with the visitor's own full IP address, the approximate location worked out from it, and details of their browser, such as its user-agent string. Neither of our own log lines records it.

3.3 How long it lives

Every link you create in the app carries an expiry date; the app offers no link without one. The default is 24 hours. You can choose 7 days instead, and with a Zhiva subscription 30 days or a date you pick, up to a year. Once a link expires it stops working: the address then returns a generic "this link is no longer available" page, which is the same page an address that never existed returns.

3.4 How you revoke it

Open the pet in Zhiva and tap Share. Every link for that pet that is still live is listed there, each with a control to revoke it. Revoking takes effect immediately and applies to everyone holding that link. It cannot be undone — a revoked link can never be re-enabled, though you are free to create a new one.

One limit is worth stating plainly. The pet's photo is not stored in the page; the page embeds a temporary link to Zhiva's Supabase storage that is valid for up to one hour, and anyone who opens the page can use it to fetch the photo from storage. That link contains internal identifiers for your account (the random ID described in §1.2) and for the pet, so anyone holding the share link can see those identifiers in the page's source, and Supabase's request log records them each time the photo is fetched. Revoking the share link stops the page at once, but a photo link that has already been handed out keeps working until that hour runs out. Everything else — the vitals, the observations, your notes — is unreachable the moment you revoke.

3.5 What we do not do with it

Creating a share link does not transfer your records to us for our own purposes, or to anyone else for theirs. The contents of a shared page are not sold, are not used for advertising, and are not sent to Anthropic. The processors that handle them are described in §6: Supabase, which already stores your records and runs the code that builds the page, together with the providers Supabase uses in turn; and Cloudflare, whose network the finished page passes through on its way to the visitor. Cloudflare's part is a pass-through: our program there holds the page in memory only for as long as it takes to send it on, and marks every share-page response no-store, which tells Cloudflare's network and the visitor's browser not to keep a copy. The page is built from your own records each time it is opened, and we do not keep a copy of it. Deleting the pet, or your account, removes the records the page is built from; see §7.

4. What We Do Not Collect

5. On-Device Storage

Zhiva uses iOS UserDefaults to persist on-device preferences (selected pet, notification settings, onboarding state, your answer to the scan consent step, and the diagnostics opt-out). These values are read and written on your device only and are never transmitted off-device.

Offline scan documents are queued in your device's Application Support directory and uploaded to your account when connectivity is restored. File timestamps on these queued items are read solely to manage storage (FIFO eviction) — they are not transmitted and are not used for any tracking purpose.

6. Data Storage and Security

Pet health records, documents, photos and diagnostic events are stored on Supabase infrastructure. The Supabase company Zhiva contracts with is Supabase Pte. Ltd., registered in Singapore. Zhiva's database and file storage are hosted in Supabase's us-west-2 region, in Oregon, USA. The server code behind some features, including the share page, can run in whichever Supabase region is closest to the person making the request.

Supabase in turn uses other companies to provide its service. Its published list of sub-processors names Amazon Web Services and Cloudflare, among others, as hosting providers. Zhiva's us-west-2 region is an Amazon Web Services region, and requests from the app and from share pages reach Supabase through Cloudflare's network. Zhiva also uses Cloudflare directly, as the next paragraph sets out.

The zhiva.app website — this policy, the terms of use, the support and walk pages, and the share pages described in §3 — is served by Cloudflare, Inc., in the USA, under Zhiva's own account with it. For a share page, Cloudflare does more than serve a file: a small program of ours runs on its network, takes the request, and passes it to Supabase, as described in §3.2. Cloudflare's own privacy policy covers what it does with the information it handles for itself.

Data in transit is encrypted with TLS. Data at rest is encrypted by the database provider. We apply Row-Level Security so that each account can access only its own records, and the storage buckets holding your photos and documents are private — nothing in them has a public address. The app opens a file through a short-lived signed link issued to your account, and a share page you create carries a short-lived signed link to the pet's photo for whoever opens it (see §3.4).

Anthropic, Supabase and Cloudflare process data for Zhiva under their terms with us, each of which includes a data processing addendum: Anthropic's Commercial Terms of Service and Data Processing Addendum, Supabase's Terms of Service and Data Processing Addendum, and Cloudflare's Terms of Use and the Data Processing Addendum they incorporate. Each company's own privacy policy (Anthropic, Supabase, Cloudflare) covers the information it handles for itself, not the data it processes for Zhiva.

7. Data Retention and Deletion

We retain your account data for as long as your account is active. Route coordinates from a walk are automatically cleared 90 days after that walk ends.

You can delete your account at any time from within the app: go to Settings → Delete Account. Deletion of your account and records is immediate and cannot be undone. It deletes your account, your pets and all of their records, and removes the documents and photos you have stored. Diagnostic and authentication event rows are kept with the account identifier removed, so those rows cannot be tied back to you. Deleting your account does not remove entries already in Supabase's request log or sign-in log (§1.6), or in our share-page log line (§3.2); those entries age out as described there. Request-log entries carry your account identifier for requests the app made while you were signed in; sign-in-log entries carry your account identifier and email address, and deleting your account adds one more, recording the deletion. Two internal records also keep your account identifier after deletion: the list of your stored files that Zhiva uses to confirm each file was deleted, which includes the files' storage paths and names, and a record of when the account scanned each document during a subscription's free trial. A document scan still being processed in the hour before you delete your account can also leave a short-lived working record, with your account identifier and what was read from the document; it is removed automatically within about 75 minutes. If you cannot access the app, you may instead email support@zhiva.app to request deletion, and we will process it as soon as possible (within 30 days at the latest).

8. Children

Zhiva is not directed at children under 13. We do not knowingly collect information from children under 13. If you believe we have inadvertently collected such information, contact us and we will delete it promptly.

9. Changes to This Policy

If we make material changes, we will post the revised policy on this page and update the dates above before the changes take effect. Please check this page from time to time; the “Last updated” date shows when it last changed. Continued use of Zhiva after a change takes effect constitutes acceptance of the revised policy.

10. Contact

Questions or privacy requests: support@zhiva.app