Privacy Policy
Last updated: September 2, 2026
This Privacy Policy explains how Nabta (“we”,
“us”) collects, uses, transfers, retains, and protects information when
you use the Nabta mobile app (package
com.nabta.app) and its backend at
api.mynabta.app. It applies specifically to Nabta.
1. Who we are
Nabta is a plant-care app that identifies plants from photos and helps you look after your garden. For a privacy question or request, contact saleh.labs.dev@gmail.com.
2. Data we collect, use, and store
“Collect” below includes data sent off your device, even when we process it only briefly. We do not sell personal data, use ads or cross-app tracking SDKs, or collect advertising identifiers.
| Data | Collection and purpose | Nabta storage and retention |
|---|---|---|
| Account identity: Google email address, Google account ID, display name, Google profile-photo URL, Nabta account ID, Clerk mirror ID, app language, and any legacy app-generated installation ID; account creation and last-seen times | Required for Google Sign-In, account security, account management, and a localized service. Creation/last-seen times support account operation and security. Google supplies the email, Google account ID, display name, and profile-photo URL; Nabta generates its internal account ID and records the app language, and Clerk can return its mirror ID. The current app no longer creates or sends the legacy installation ID, but an older account row can still contain one. | Stored with your Nabta account until you delete the account. The profile-photo URL is stored; Nabta does not store a copy of the Google profile-photo file. |
| Plant-identification photos and photo-derived records | A photo you choose is sent to Nabta and then to the configured identification provider to identify the plant. Nabta re-encodes it first to remove embedded metadata before the provider transfer. The fingerprint, digest, and result metadata support safe retries, quota accounting, abuse prevention, and avoiding duplicate charges. Supplying a photo is optional, but identification cannot run without it. | The identification operation processes its image bytes in memory and does not by itself save an image file. We do retain an account-linked, one-way SHA-256 image fingerprint, an idempotency/request digest, and identification result/usage metadata. The idempotency registry is scheduled for deletion after 1 day; stored result payloads in the usage audit are scheduled to be cleared after 90 days; and the remaining identification audit rows, including the image fingerprint, are scheduled for deletion after 365 days. Account deletion removes them earlier. |
| Private garden plant photos | When you explicitly add an identified plant with its selected photo, or add or replace a photo for an existing garden plant, Nabta re-encodes that photo as a bounded JPEG, applies its orientation, and removes embedded metadata. The private copy is linked to that garden plant and account so Nabta can show it on your devices and restore it after reinstalling the app and signing in. Nabta also keeps a replaceable copy in the app-private storage on each device where you view it; no broad shared-storage permission is used. | The server copy and its content digest, opaque revision, byte count, media type, and timestamps are stored until you remove the photo, delete the garden plant, or delete your account. A device removes its cache when it performs or observes the photo/plant/account deletion, and on sign-out, account switch, cache eviction, or app deletion. An offline device can retain its app-private cache until it reconnects and observes the deletion or one of those local cleanup events occurs. Deleted database bytes can remain in access-restricted daily disaster-recovery backups. Those backups follow a 14-day deletion schedule; a failed cleanup can delay removal until maintenance succeeds. |
| Plant identification and care-content reports | If you use the in-app flag, Nabta stores the selected reason and any optional details you write; the form tells you not to include personal or sensitive information. To keep the report inspectable after the short retry record expires or a garden plant changes, Nabta also captures a bounded immutable snapshot of only the plant output you saw: the displayed dictionary names, provider suggestion, confidence and not-found result for identification, or the localized plant name and care fields for a care report. It records the content source/provenance, report context, integrity digest, timestamps, and review status. The snapshot never includes the plant photo or photo hash, nickname, site label, or account profile fields. Content whose origin is unknown remains labelled unknown; Nabta does not call curated content AI-generated merely because it is reportable. | The report, optional user-written details, immutable output snapshot, and status are linked to your account and scheduled for deletion after 180 days; account deletion removes them earlier. Deleting only a garden plant leaves an already-submitted report and its bounded snapshot available for that review period, while removing the garden-row link. Nabta deduplicates one report per content kind and displayed content version; exact retries return the original acknowledgement. |
| Garden records: selected plant, optional nickname, optional site label, latest and next watering timestamps, record timestamps, and add-request identifiers/digests, including a saved-photo digest when a photo is attached | Used to show your garden, organise plants, calculate the next watering date, prevent duplicate adds, and schedule reminders. A site label such as “Living room” is user-entered grouping text, not a GPS location. | Stored until you delete that plant or your account. Nabta stores only the latest watering time and next due time, not a complete watering history. |
| Previously saved approximate garden weather location | The current release does not collect a new garden weather location, read device location, geocode a city, or send location to a weather provider. Weather-adjusted watering is disabled. A coarse coordinate pair and display label saved by an earlier version may still remain on your account. | While the feature is disabled, historical values do not affect watering and are not sent to a weather provider. Settings provides a removal-only control that clears any saved value; account deletion also clears it. Legacy per-plant coordinates were permanently erased. |
| Subscription and purchase information | Google Play handles payment. When configured, the RevenueCat SDK can first create a RevenueCat App User ID; Nabta then asks it to bind the customer to your Nabta account ID, and RevenueCat can retain the identifiers as customer aliases. The SDK sends those identifiers and purchase/receipt information to RevenueCat to validate purchases, restore them, and manage entitlement. Nabta’s backend receives subscription status, plan/product and entitlement identifiers, the provider App User ID, purchase/expiry/renewal dates, and bounded webhook event metadata. Nabta does not receive or store your card/bank details or the raw Google Play purchase token. | Current entitlement and quota state is stored until account deletion. Stored webhook payload fields are scheduled to be cleared after 90 days, and terminal billing audit rows are scheduled for deletion after 365 days. Google Play and RevenueCat keep their own transaction records under their policies and legal obligations. |
| Quota and promotion activity | Nabta records identification/plant allowance counters and, if you redeem a promotion, the submitted promo-code value and bonus amounts. These records apply the benefit once, enforce plan limits, and prevent repeat redemption. | Stored with your account until account deletion. They are not sent to an advertising or marketing partner. |
| Ask Flora AI chat feature: messages, generated replies, and reports, where available | Your prompt and the conversation history you submit are sent to Nabta. For an ordinary AI answer, Nabta sends them to Google’s Gemini AI to generate the reply. When Nabta’s safety filter detects a message about possible human or animal ingestion, exposure, poisoning, acute symptoms, medication, or an emergency, Nabta returns a fixed plant-care-scope refusal and directs you to an appropriate qualified professional or local service without sending that message to Gemini. The refusal does not assess severity or provide medical, veterinary, first-aid, diagnosis, treatment, or exposure-management instructions. Messages and history are not persisted as plaintext in Nabta’s database. Do not include personal, sensitive, or confidential information. If you choose to include health or plant-exposure details, they are processed as part of that message under the same rules. Nabta stores a keyed, non-reversible request digest and content-free request/usage metadata such as request IDs, locale, status, token counts, cost units, and model/prompt/filter versions. | An encrypted copy of a generated reply is readable for no more than 24 hours so a retry can return the same answer without a second charge; the content-free request row remains through the 72-hour report-receipt window. If you report a reply, Nabta stores the exact reply encrypted at rest, the selected reason, account/request identifiers, and moderation/audit metadata for 30 days. Authorised reviewers can decrypt that reported reply during the review period. One generated reply can create one report; a report never adds your prompt or surrounding conversation. Flora usage counters and content-free usage ledgers remain until account deletion. |
| Crash logs, when reporting is enabled | Crash reporting starts off. It sends only after you explicitly enable it in Settings › Diagnostics and secure storage contains that exact opt-in. A missing, malformed, unreadable, or timed-out stored choice leaves reporting off. Turning it off takes effect immediately and clears queued reports; if the new choice cannot be saved, reporting stays off and Settings shows the failure. When enabled, Nabta sends the exception class name, a bounded scrubbed list of code frames, reporting surface, app version, build mode, platform, major OS version, and app language. The diagnostic payload excludes the exception message, photos, plant/site labels, email, auth token, and account or device ID. | Stored as one unlinked aggregate per full crash signature, including the listed diagnostic fields, first/last-seen times, and an occurrence count. It is not keyed to a Nabta account and the crash request carries no authentication header; the network edge separately processes the request IP as described in the next row. A daily cleanup is configured to delete a signature 90 days after it was last seen; another occurrence restarts that 90-day period. Because the aggregate is not account-linked, account deletion does not select or remove it. |
| Network, request, and operational logs | Each online request necessarily sends the client IP address, timestamp, HTTP method, request target (path and query), and standard headers such as referrer or user agent when the client supplies them to Nabta’s network edge. The edge processes that metadata to route and secure the request, but the active Nabta access log stores only client IP address, timestamp, HTTP method, status, response bytes, and request duration. It does not store the request target, path, query, referrer, or user agent. The selected Nabta locations also disable Nginx request error logging because that fixed-format stream can repeat an unredacted request target; status and duration remain in the minimal log. Failures that occur before Nginx can select a Nabta location can still enter the shared host error log. Application request summaries use route templates; some other application events contain an opaque Nabta, Clerk, RevenueCat event, plant, or request identifier. Application logs do not deliberately include request bodies, authentication headers, plant photos, or Flora prompt/reply text. Nabta does not use the request IP to infer your physical location. | These are separate from account records. The minimal edge log rotates daily and retains 14 archives. New Nabta application events are confined to an isolated journal that retains them for at most 30 days and is capped at 128 MiB, so size pressure can remove them earlier; it is not forwarded to the host-wide syslog. Existing entries made before these controls were not purged: old combined edge and Nginx error entries can contain the former raw request line (including path and query), referrer, and user agent and age out under the same daily/14-archive rotation. Older application entries can contain raw paths, opaque identifiers, or provider error strings; forwarded copies age under 4 weekly archives, while copies in the shared host journal remain subject to its storage management without a guaranteed fixed maximum age. A host-level Nginx error that occurs before Nabta-location selection can follow the shared Nginx daily, 14-archive rotation; requests handled by a Nabta location do not create that error stream. Operational entries can therefore remain after account deletion until the applicable current or legacy storage rule removes them. |
Watering reminders are scheduled on your device; Nabta does not collect a push-notification token. We do not collect contacts, audio, videos, advertising IDs, or the contents of unrelated messages. Local camera/gallery access is used only for a photo you choose for identification or explicitly attach to your private garden.
3. Service providers and other transfers
We transfer only the data needed to provide and secure the service:
- Google — Google Sign-In supplies your account profile; Gemini receives a selected plant photo for identification and the prompt/history used for an ordinary Ask Flora AI answer; Google Play handles purchases and payment.
- RevenueCat — receives its SDK-generated App User ID, your Nabta account ID, and purchase/receipt history for subscription validation and management; it can retain the identifiers as aliases for one customer.
- PlantNet — receives a selected, re-encoded plant photo when it is configured as the identification provider.
- Clerk — is a best-effort account mirror and may receive
your email, display name, Nabta account ID, and a username derived from the part
of your email before
@(or from the Nabta ID when no email exists). - Amazon Web Services — hosts Nabta’s backend, database, network edge, and operational logs.
Platform location/geocoding services and Open-Meteo receive no garden location from the current release because that feature is disabled. Nabta will update this policy and the in-app flow before resuming location collection. We may also disclose information when required by law.
4. Retention and deletion limits
The table above separates account storage, short-lived replay/audit storage, provider records, and operational logs. Scheduled cleanup runs daily, so a row becomes eligible at the stated age and is physically removed by a later cleanup cycle; an outage can delay physical cleanup. Account deletion removes account-linked Nabta database rows without waiting for those schedules. Daily PostgreSQL disaster-recovery backups, including private garden photos, are access-restricted and follow a 14-day deletion schedule. A failed cleanup can delay removal until maintenance succeeds, so deleted database content can remain in a backup until cleanup completes.
Encrypted Flora replay content cannot be decrypted after its 24-hour expiry, even if physical cleanup has not run yet. A reported Flora reply has a 30-day expiry and is removed with its moderation/access audit rows. Google Play, RevenueCat, Google identity, and other providers control their own copies under their policies; Nabta’s in-app database deletion does not by itself erase every provider record.
A plant identification/care report, including its optional user-written details, bounded output snapshot, integrity digest, and review status, is scheduled for deletion after 180 days. It is removed sooner with the Nabta account, but not merely by deleting the reported garden plant.
5. Security
Data is encrypted in transit using HTTPS/TLS. Authentication tokens on your device are kept in platform secure storage (Android Keystore). Flora replay and reported-reply content is encrypted at rest with purpose-separated keys; this is not end-to-end encryption because the backend and authorised reviewers must be able to process the content for the stated purposes.
6. Your rights and choices
You can request access to, correction of, or deletion of your personal data. You can delete individual garden plants, clear any weather location retained from an earlier release in Settings, choose whether to enable crash reporting (it starts off), and delete your Nabta account in the app. You can also email saleh.labs.dev@gmail.com for a verified privacy or provider-side deletion request.
7. Account and data deletion
You can permanently delete your Nabta account:
- In the app: open Profile / Settings → Delete account. A successful request immediately erases the account-linked rows in Nabta’s database and signs you out.
- By email: see Delete Account or email saleh.labs.dev@gmail.com from the Google account email you use with Nabta so ownership can be verified.
Nabta database deletion covers the profile, garden, previously saved weather location, private garden photos, local subscription/quota state, identification hashes/audits, and Ask Flora request, usage, and report rows, plus plant identification/care reports and their optional details, bounded output snapshots, and statuses. It does not remove unlinked crash aggregates or immediately remove rotated operational logs. Clerk deletion is best effort after the Nabta database commit. Google Play transaction records and RevenueCat customer/purchase history are separate provider records; contact us for a provider-side deletion request where deletion is available.
If you have an active subscription, cancel it in Google Play. Deleting your Nabta account does not cancel the Play subscription.
8. Children’s privacy
Nabta is intended for general audiences and is not directed to children under 13. We do not knowingly collect data from children. If you believe a child has provided us data, contact us and we will delete it where applicable.
9. Changes to this policy
We may update this policy; we will revise the “Last updated” date above and, for material changes, notify you in the app.
10. Contact
Questions or requests: saleh.labs.dev@gmail.com.