Privacy Policy

Last updated: 2026-09-04

What we collect

When you sign in with Google, we receive your name, email address, and profile picture. When you create a birth profile, we store the name, date, time, and place of birth you provide, along with the resolved latitude, longitude, and timezone. If you add a current city, we also store that place and its resolved latitude, longitude, and timezone.

The guest profile tools used from Panchangam do not require an account. A guest profile name stays in that browser. If remote calculation is enabled, this service receives a place-search query and then the selected coordinates, timezone, birth date, and birth time needed for the requested calculation; it does not save a guest profile in the Astro Chaganti account database.

How we use it

Your account information is used solely to identify you within the app and link saved profiles to your account. Birth profiles are used to compute astrological readings on demand and are stored so you can view them again later. We do not sell your data or use birth data for advertising. We send only the information needed to the service providers described below.

Service providers

  • Google — for sign-in.
  • OpenStreetMap Nominatim — receives only the city or town text that a guest or signed-in user deliberately submits to find a birthplace or current city. The initial deployed geocoder uses this fixed public service with an identifying application User-Agent, bounded caching, shared pacing, and linked attribution. Search runs only after submission, not as autocomplete, and the form instructs users to enter a city or town rather than a street address. See the Nominatim usage policy.
  • OpenStreetMap contributors — the configured geocoder may use OpenStreetMap data, with linked attribution where results appear.
  • DashaFlow sidecar — receives the bounded birth or election-chart inputs needed to perform an astrological calculation.
  • Turso (libSQL) — stores signed-in account profiles and readings. Its separate limiter tables contain only environment-scoped HMAC digests with integer count/expiry fields, plus one non-personal aggregate provider quota-and-admission-lease row shared across deployed environments. Those limiter tables never receive raw IP addresses, user IDs, place queries or results, birth details, coordinates, provider keys, or profile data.
  • Vercel — hosts the application and its server functions.
  • Sentry — error and performance monitoring. Server request-body capture is disabled, and geocoder request URLs are excluded and scrubbed so place queries and provider keys are not sent in traces.
  • PostHog — product analytics. Guest calculation routes do not add profile names, birth payloads, or chart data to analytics events.

Retention and caching

Signed-in profiles remain until you delete them. In a deployed managed geocoder flow, this application caches normalized location results only in bounded server-process memory for up to 24 hours under a hashed key. They are not persisted as a shared result cache or written to limiter tables. If a signed-in user selects a location and saves a profile, its place, coordinates, and timezone are stored as profile fields as described above; guest selections are not. Short-lived pseudonymous limiter rows become obsolete when their enforcement window expires and are removed by bounded maintenance. The non-personal provider budget row rolls over by UTC day. Each external geocoder may retain request data under its own published terms, which must be reviewed before activation.

Your choices

You can delete any saved profile at any time from your dashboard. To delete your account entirely, email astrochaganti@gmail.com.