Privacy, explained.

Who this policy covers

Sky Catalog by DeepSkySpace (referred to as “Sky Catalog” in this policy) is operated under deepskyspace.com. This policy covers the customer platform (APP), Sky Catalog Business (CMS), and the services supporting them. It applies to visitors, customers, people making guest enquiries, business owners, CMS staff and people contacting platform support.

Sky Catalog handles information to operate the platform. A listed business also receives and uses information needed to fulfil its bookings, enquiries and asset support requests. That business is responsible for its own handling of those records, including copies it downloads or receives by email. Its privacy notices may also apply to its separate services.

Google sign-in: access, use and your choices

Google sign-in is an optional way to access the Sky Catalog customer platform and existing accounts on the business CMS. Email-and-password signup and sign-in remain available. New CMS accounts require signup with an owner-issued app secret key.

When you choose Continue with Google, we request openid, email and profile permissions. Google supplies identity claims that can include a unique account identifier, email address and verification status, first and last name, profile picture and a managed-account domain. Our backend validates the identity and uses the account identifier, verified email and available names for sign-in or account creation. The managed-account domain, when supplied, helps assess whether an existing email account can be linked securely. We do not save or display the Google profile picture.

We use this information to authenticate you, securely link an eligible existing Sky Catalog account, prefill signup details and deliver the account and booking features you request. Additional profile fields, such as your contact number and location, are supplied by you in Sky Catalog, not read from Google. We do not request access to Gmail messages, Google Drive files, Calendar, contacts or other Google Workspace content.

• Storage and protection: the Google account identifier is linked to your Sky Catalog user record; your email and completed profile are stored with your account. Limited identity details may also be held temporarily while signup completes. Google credentials are exchanged and checked on the backend over HTTPS; this integration does not persist Google access or refresh tokens for ongoing API access. Database access is restricted to the application and authorised administrators.
• Sharing: names and email used in your Sky Catalog profile are shared with the relevant business when needed to fulfil your bookings, enquiries or support requests, and with the infrastructure/email providers described below to operate those features. The Google account identifier is not included in business-facing booking or enquiry records. Platform staff may access information for requested support, security, reconciliation or legal obligations.
• Use limits: we do not sell Google user data, use it for advertising or credit decisions, or use it to train general-purpose AI models. Its use is limited to the account, booking and supporting features described in this policy.
• Retention and deletion: we retain the linked Google identifier while the account uses Google sign-in, subject to a verified removal or account-closure request. Send such requests to the support email in Operator & contact, identifying your account and whether you want to remove the Google connection or close the account. We may verify ownership and explain any records retained for accounting, disputes, fraud prevention or legal obligations. Transaction records and backups may remain under the retention rules below.
• Revoking access: you can remove Sky Catalog from the third-party connections in your Google Account. Removing Google access does not itself delete your Sky Catalog account, cancel bookings or end an existing Sky Catalog session. Sign out of Sky Catalog and contact support if you also want the stored Google link, account data or active sessions removed.

Information we handle

• Account and profile details: first and last name, email, contact number, city, state and country; password hashes, email verification records, sessions and account status.
• Google sign-in, when you choose it: verified email, Google account identifier and basic profile details used to create or link a customer account, or link an existing CMS account. We request sign-in identity scopes, not access to Gmail messages or Google Drive files.
• Booking and commerce records: asset, dates, times, resource assignments, number of persons and resources, equipment, offers, invoices, credit notes, payment references and statuses, cancellations, rescheduling and refunds. Business QR scans create scan records; a scan count is not proof of attendance.
• Enquiries and support: your name, email, contact details and messages, the related asset/business, status updates, and whether a platform support request came from APP or CMS. Guests provide their own contact details.
• Business administration: business and legal names, address, tax details, public listing content, support contacts, staff names and emails, permissions, assigned assets, gateway settings, payout beneficiary/bank details, verification results and settlement records.
• Optional nearby discovery: after you agree and approve the browser prompt, we round your location to three decimal places and store it in a browser cookie for up to 24 hours. We use it to sort the catalog by approximate straight-line distance; we do not add it to your account or continuously track you. You can turn nearby sorting off and continue searching all assets.
• Technical and usage information: session identifiers, basic asset page-view events, security/rate-limit records and infrastructure logs, which may include IP address, browser/request information and timestamps. We use a browser-session identifier to deduplicate asset views.
• Reach out requests: first name, last name, company, email and any optional comment you submit to ask the platform owner about CMS access.

Why we use information

Provide only information needed for your request. Do not include payment PINs, passwords, identity-document copies or sensitive information about another person in free-text messages. If you provide someone else’s details, you must have a lawful basis and authority to do so.

• To verify accounts, provide sign-in and maintain account security.
• To display listings, route enquiries and support, reserve resources and equipment, confirm bookings and let businesses manage delivery.
• To process and reconcile payments, refunds, bank verification, invoices and business settlements; investigate disputes and prevent duplicate or fraudulent transactions.
• To send requested verification codes and transactional notices about account, enquiry, booking, cancellation, refund or settlement activity.
• To provide business analytics and aggregate asset-view counts, diagnose faults, prevent abuse and respond to legal obligations.

Who receives information

The current application does not sell personal information or implement advertising audiences. Listing descriptions, images, location and published business/asset support details are intended to be seen by others. Do not put private customer or staff information in a public listing.

• The relevant listed business and its authorised staff receive the customer and transaction details needed for their bookings, enquiries and asset support. Staff access is restricted by their business permissions and assigned assets. Business owners retain access to their own business records.
• Platform administrators handle onboarding, platform support, asset reports, payment reconciliation, settlements and abuse investigations. Sky Catalog reviews reports; relevant information may need to be shared with the business to investigate or resolve a complaint.
• Razorpay processes checkout payments and refunds; RazorpayX may process business bank verification and settlements when configured. Google provides optional sign-in for customers and existing CMS account holders. Resend delivers transactional emails. Vercel hosts the frontends and Google Cloud hosts the API/database. These providers process information needed for their respective services under their applicable terms and privacy practices.
• Geoapify supplies address lookup and map tiles in the CMS. When a business searches an address, the supplied venue address is sent to Geoapify; loading map tiles also sends the browser request information to that provider. Confirmed venue coordinates are stored with the public asset listing. Customer nearby sorting is calculated by Sky Catalog and does not send customer coordinates to the map provider.
• The Reach out form sends its submitted fields to the platform owner’s contact service, operated for the deepskyspace.com project, so the owner can respond about business onboarding.
• Information may be disclosed to advisers, payment partners or authorities when necessary to investigate a dispute, protect the service, respond to a lawful request or meet a legal obligation.

Payment and bank information

Payment credentials are entered in the payment provider’s checkout. Sky Catalog handles transaction identifiers, amounts, statuses and provider responses needed to confirm and reconcile the payment; we do not ask you to submit card security codes or UPI PINs through our enquiry or support forms.

A business may choose the platform gateway or configure its own gateway. We store gateway secrets and business bank details in encrypted form where those features require them, and restrict administrative access. Business bank verification and payout records are separate from customers’ checkout records. A provider’s own privacy notice also applies to information it handles.

Cookies and browser storage

• APP and CMS use separate session cookies to keep you signed in. Sessions normally expire after seven days and may be revoked earlier. Production session cookies are marked Secure and HttpOnly.
• A short-lived cookie is used during optional Google sign-in to protect the authentication flow.
• Local storage remembers your appearance and location-prompt choices. An optional nearby-location cookie stores approximate coordinates for up to 24 hours. CMS storage also remembers your selected asset and financial mode. Session storage holds a random visit identifier used for asset-view counts.
• Payment and sign-in providers may use their own cookies or storage when their services are opened. Blocking necessary cookies can prevent sign-in or checkout. Clearing browser storage does not delete records already held on the server.

Storage, retention and security

The current backend and primary database are hosted on Google Cloud in Mumbai. Frontend hosting, email, sign-in, payment services, logs and backups may involve processing in other locations. We do not promise that every copy stays in India.

Account, business and transaction records are kept to operate the service and address accounting, tax, reconciliation, dispute, fraud-prevention and legal requirements. Duration depends on the record and those requirements. Expired verification/session records and queued email content have operational cleanup rules; not every record category has automatic deletion.

Account closure and deletion requests are handled through support. We review which records can be deleted or de-identified and which must remain for a stated lawful purpose. Backups and recipients’ independent records may not be removed immediately. Closing an account does not itself cancel a booking or erase invoices.

We use access controls, password hashing, encrypted sensitive business credentials and transport security in production. No storage or transmission method can be guaranteed completely secure. Contact support promptly if you believe an account or record has been compromised.

Your choices and privacy requests

You can update supported profile fields in account settings, change your password and sign out. Contact platform support from the email linked to your account to request access, correction, deletion, account closure or withdrawal of consent for a specific optional use, or to raise a privacy grievance. Please identify the request and relevant account or booking without sending passwords or payment secrets.

We may ask for proportionate identity or authority verification before changing or disclosing records. We will explain any restriction needed for another person’s rights or an applicable legal obligation. Withdrawing information needed to deliver a service may mean that service can no longer be provided. Applicable statutory rights and complaint routes remain available.

This notice explains processing; it is not a blanket consent to unrelated marketing or new uses. Any new use that requires separate consent must be presented separately.

Children and other participants

Accounts and payment transactions are intended for adults aged 18 or over who can enter into a contract. An adult arranging an activity involving children must follow the venue’s rules and applicable consent requirements. Do not submit children’s personal details unless specifically needed and lawfully authorised. If a child has supplied information through an account or form, contact us so we can review it.

Changes to this policy

We will update this page when our data practices change and identify the revision and effective date. Where a material change requires notice or consent, we will provide it through an appropriate channel before the new use. A notice update does not remove rights provided by law.

Business billing, mandates and login security

For business subscriptions and remittances we record the accepted tier, limits, billing interval, price and tax snapshots, offer redemptions, service periods, immutable invoices or debt statements, fixed due dates, payment receipts, adjustments and collection communications. Subscription invoices and money owed from customer bookings are separate obligations.

Razorpay processes subscription mandate authorisation and payments. We retain provider plan, mandate, invoice, order and payment references and status events for confirmation and reconciliation. We do not store full card numbers, CVV, UPI PINs or bank authentication secrets. Stopping a mandate does not erase an existing invoice or historical record.

Business owners must complete an email verification code after password or Google sign-in. We store hashed codes, a short-lived pending-login token hash, request/expiry times and attempt counts to prevent unauthorised sessions. Ordinary CMS staff follow the configured staff sign-in flow.

We record the version and document hashes of the business terms and privacy notice accepted at onboarding and the acceptance time. A copy is attached to the welcome email. Billing and acceptance records may be retained where needed for accounting, security, disputes or legal obligations, even after access ends. Contact the grievance officer for access, correction, deletion or retention questions.