Trust
Privacy notice
Last updated: 2 August 2026
Who we are
BookMyMandir is a product of XALEN Technology Private Limited. The published legal identity is XALEN Technology Private Limited, CIN U72900PN2024PTC230853, GSTIN 27AAACX6117C1ZL, with registered office at Pune, Maharashtra 411041, India. Company and missing-contact particulars are listed here. BookMyMandir provides software for temple profiles, listings, enquiry records, a devotee register, consent-gated communications and record-only donation operations. A temple decides why and how it uses its devotee records; BookMyMandir processes platform records on its instructions where applicable. Final statutory and contractual roles depend on the applicable agreement and law. Grievance-officer and monitored-channel particulars remain unpublished rather than guessed.
What we collect
Temple account and verification records may include the account holder's name, email, role, represented institution, legal-entity and contact details, evidence submitted for manual review, staff invitations, access roles and audit events. Temple-entered records may include devotee name, email, phone, purpose and channel-consent history; listings, enquiries, helpdesk records and record-only donation operations may include the contact and notes supplied for that workflow. Public booking enquiries can include name, phone, email, note and source provenance. BookMyMandir-owned lead, claim, enterprise and support forms collect the fields shown in the form plus page/source context. A published temple intake form records its exact immutable form revision, displayed processing purpose, notice acknowledgement, normalized answers and scheduled-expiry snapshot. That acknowledgement does not create email, SMS or WhatsApp consent, and responses are never public by default. Security controls may retain pseudonymous rate-limit, idempotency and abuse evidence; raw network addresses are not intended to be stored in those application records. We do not sell or rent personal data.
Why we use it and who decides
BookMyMandir uses account, lead, support and security records to operate the service, respond to requests, verify claimed operator relationships, protect public forms and meet applicable legal obligations. For temple-controlled devotee, enquiry, communication and operating records, the temple normally decides the purpose and authorised users and BookMyMandir processes the records for that workspace where applicable. The precise controller, processor or other statutory role depends on the record, applicable agreement and law; this notice does not replace that agreement.
Consent
Every devotee contact carries a consent state per channel. Current campaign audiences include only granted contacts, and the bounded email path rechecks consent immediately before each provider submission. Each outreach campaign also declares a purpose. A private, expiring link in each attempted outreach email lets the recipient suppress individual purposes or withdraw email consent. Purpose choices never create channel consent, and a self-service link cannot grant withdrawn consent again. The preference history is recorded with the notice version and source that produced it.
Where data lives
The primary application data plane is configured in AWS Mumbai (ap-south-1). Email and authentication services and other approved providers may process limited identity or delivery data outside that region under their own terms. Authorised temple staff receive records for their own workspace; BookMyMandir operations staff receive only the records needed for support, lead handling or manual verification. Information may also be disclosed where law, safety or fraud prevention requires it. A complete public subprocessor/DPA list, backup-residency commitment and cross-region transfer assessment is under legal review and is not represented as finished here.
Current retention boundaries
Public booking enquiries, per-temple helpdesk records and distribution-attribution evidence currently carry a 365-day application expiry. BookMyMandir-owned lead, claim, enterprise and product-support submissions carry a 180-day expiry. A temple form chooses a fixed 30, 90, 180 or 365-day response-expiry snapshot when its revision is published; expired responses are hidden from the operator reader while DynamoDB TTL cleanup remains asynchronous. Changing a later form revision does not extend an existing response. Email preference and consent history, tenant verification evidence, account/audit records and temple-controlled operational records do not yet have a complete automated deletion schedule in every workflow; they remain subject to the applicable agreement, legal need and manual request process. Expiry is a storage-control boundary, not a promise that provider backups disappear at the same instant.
Your rights
A temple workspace owner can take one complete self-service archive of that workspace's own records, and can close the workspace themselves. The archive excludes credential material, BookMyMandir security and operations data, and the separate software-billing ledger; those exclusions are named in the archive manifest. Closing a workspace removes public access and revokes seats but retains records, so it is not proof of erasure. Self-service correction and devotee-level deletion tools are still on the roadmap. A devotee or temple may contact the temple or us to request access, correction, withdrawal or erasure. We may need to verify identity and authority, identify the applicable controller, preserve records required by law, and coordinate with the relevant temple or provider. Requests are handled manually through the privacy contact below. This page does not promise an automated statutory workflow, fixed response SLA or grievance mechanism that the product and legal review have not completed.
Security and unfinished legal work
The source implementation uses tenant-derived access controls, bounded inputs and explicit verification gates for sensitive workspace actions. No source label is proof of deployed production security. A complete retention engine, data-subject request workflow, India grievance-officer publication, counsel-approved subprocessor register and DPDP role matrix remain open release work.
Contact
A named grievance officer and monitored grievance mailbox are not yet available. The first-party privacy-request form records an intake request, but it is not represented as a monitored statutory grievance channel and no response SLA is promised. Record a request on the first-party privacy intake form.
This notice reduces operational risk and describes our practices. It is not legal advice.