Legal

Privacy & Data Handling Policy

Ruver Dashboard. Last updated: 21 July 2026

1. Overview

The Ruver Dashboard (“the Application”) is an internal seller-operations tool used by Ruver (“we”, “us”) to manage its own listings, orders, inventory and settlements on Amazon.in. The Application is not offered to the general public and is accessible only to authorised operators of Ruver.

This document combines our Privacy Policy (how we collect, use and protect personal data) and our Data Handling Policy (the internal controls applied to Amazon information and Personally Identifiable Information). It is published to satisfy Section 2 of Amazon’s Selling Partner API Data Protection Policy and the documentation requirement of the Restricted Data Access role application.

2. Data We Collect

2.1 Selling Partner API data

Through the Selling Partner API (SP-API), we receive and process the following categories of information for orders, listings and settlements that belong to our own Amazon seller account:

  • Order summary fields (order ID, purchase date, status, total, currency, marketplace, fulfilment channel)
  • Order items (SKU, ASIN, quantity, item price, shipping price, tax)
  • Financial events (shipments, refunds, fees, promotions, tax withheld)
  • Inventory and listings data (SKU master, stock levels, product attributes, images)
  • Traffic & conversion reports (sessions, page views, buy-box, conversion rate)
  • Advertising performance (impressions, clicks, spend, sales — when configured)
  • Anonymised shipping address fragments returned by default (city, state, postal code)

2.2 Buyer Personally Identifiable Information (PII)

Buyer PII (recipient name, full address, contact phone number, buyer email) is only retrieved on explicit operator action through the “Reveal” control in the order detail view. Each retrieval is performed through a fresh, short-lived Restricted Data Token (RDT) issued by Amazon, scoped to the specific order and data element being read, and discarded immediately after use. PII is never written to our database.

2.3 Operator authentication data

Authentication is provided by Firebase Authentication. We process operator email addresses, sign-in timestamps and minimal device metadata for the purpose of access control. Passwords (when used) are stored only by Firebase, never by us.

2.4 What we do NOT collect

We do not run advertising trackers, third-party analytics with PII, or any cookie that could identify Amazon end-customers. The Application is not exposed to Amazon buyers and never collects information directly from them.

3. Lawful Basis & Purpose

Processing of Amazon information is performed on the lawful basis of legitimate interest in operating our own e-commerce business on the Amazon marketplace, and where applicable, on the basis of contractual necessity with the buyer (to fulfil and ship orders they have placed).

The specific operational purposes are:

  • Fulfilling and shipping orders the buyer has placed
  • Issuing labels and tax-compliant invoices
  • Managing inventory and listing health
  • Reconciling settlements and tracking margins
  • Handling returns, refunds and customer-service follow-up

We do not use Amazon information for any purpose unrelated to managing our seller account, and we never sell or rent the data.

4. Buyer Personally Identifiable Information

Buyer PII is treated as the most sensitive category of data we handle and is governed by the Amazon Selling Partner API Data Protection Policy and the Restricted Data Access controls.

  • Opt-in retrieval. PII is fetched only when an allow-listed operator clicks “Reveal” on a specific order. There is no background sync, batch export or pre-fetching of PII.
  • Per-request authorisation. Each retrieval mints a fresh Restricted Data Token via Amazon’s/tokens/2021-03-01/restrictedDataToken endpoint, scoped to a single order and the specific data element (buyerInfo or shippingAddress). Tokens expire within an hour and are discarded immediately after the single API call they were minted for.
  • No persistence. Buyer name, full address line, and phone number are returned to the operator’s browser session only. They are never written to our database, never appear in application logs, and are not included in backups.
  • Allow-list gating. Only operators whose email appears in the PII_REVEAL_ALLOWLIST server configuration can successfully invoke a PII retrieval. The check is enforced server-side; any unauthorised attempt is recorded in the audit log and refused with HTTP 403.
  • Audit log. Every PII access attempt — allowed, denied or failed — is recorded in pii_access_log with operator identity, target order ID, requested elements, IP, user-agent and timestamp. The Incident Management Point of Contact reviews this log on a fortnightly cadence.

5. Retention

Data typeRetentionDisposal
Order summaries, items, financial eventsUp to 7 years (Indian tax records)Deleted from RDS after retention
Anonymised shipping fragments (city/state/postal)Same as order dataSame as order data
Buyer PII (name, full address, phone, email)Less than 31 days — in practice not persistedDiscarded with the browser session
PII access audit log12 months minimumPruned by quarterly job after 12 months
Application logs (CloudWatch)12 monthsAuto-pruned by retention policy
Operator authentication metadataUntil offboarding + 90 daysAccount deletion in Firebase

6. Sharing & Sub-processors

We do not sell, rent or otherwise share Amazon information with third parties for their own purposes. The following sub-processors host or transmit Amazon information on our behalf, each under a written data processing agreement:

  • Amazon Web Services, Inc. — primary database (RDS Postgres) and application hosting in the ap-south-1 (Mumbai) region.
  • Google LLC (Firebase) — operator authentication.
  • Vercel Inc. — if used, application edge hosting and TLS termination.

Logistics carriers (Delhivery, Blue Dart, DTDC, etc.) receive only the specific shipping label data required to deliver a parcel and act as independent controllers for the data they receive.

7. Security Controls

7.1 Encryption

  • At rest: AWS RDS Postgres with AES-256-GCM encryption under an AWS KMS Customer Managed Key, with annual key rotation. Automated backups inherit the same encryption.
  • In transit: TLS 1.2 or higher for all inbound and outbound traffic. Database connections require sslmode=require.

7.2 Network

  • The production database lives in a private VPC subnet with no public IP. Inbound connections are restricted to the application security group.
  • Developer endpoints connect to production resources only via AWS SSM Session Manager or a VPN bastion; direct database access from laptops is not permitted.
  • The AWS account requires SSO with MFA for all human access.

7.3 Secrets management

Application credentials (LWA refresh token, database URL, KMS key references) are stored in AWS Secrets Manager and injected at runtime. They are never committed to source control. The Git repository has push protection and secret scanning enabled to block accidental credential commits.

7.4 Backups

RDS automated backups run daily with 7-day retention, encrypted with the same KMS key. Weekly snapshots are copied cross-region for disaster recovery. Recovery objectives: RTO 4 hours, RPO 24 hours. Restore procedures are tested quarterly.

7.5 Vulnerability management

Application code is scanned on every pull request via GitHub CodeQL and dependency scanning via GitHub Dependabot. Findings are tracked in our issue tracker against fixed SLAs (critical: 7 days; high: 30 days). Periodic vulnerability scans of the AWS environment are run with AWS Inspector.

7.6 Testing & PII protection

Test and development environments never use real Amazon PII. The Application supports a DRY_RUN_MUTATIONS environment flag that suppresses outbound SP-API calls in non-production environments, allowing the user-facing flows to be exercised against synthetic data. Production database snapshots taken for debugging are run through an anonymisation script that nulls PII columns before being attached to any developer environment.

8. Data Classification

All data handled by the Application is classified into one of four tiers. Controls in sections 4, 5, 7 and 9 are mapped to these tiers.

  • Public — marketplace listings, our own catalogue. No special handling.
  • Internal — aggregated metrics, dashboards. Available to all authenticated operators.
  • Confidential — order-level financial data, settlement records, supplier costs. Available to authenticated operators with the relevant business role.
  • Restricted (PII) — buyer name, address, phone, email. Available only to operators on the PII allow-list, never persisted, every access audited.

9. Access Control & Audit

  • Every operator has a unique corporate identity (Firebase Authentication, no shared accounts).
  • PII access is gated by an explicit allow-list maintained by the security lead. Additions and removals are logged in the audit trail.
  • Onboarding follows a written checklist covering account creation, role assignment and signed acceptable-use policy. Offboarding revokes credentials within 24 hours of departure.
  • The active-user list is reviewed quarterly.
  • The PII access log is reviewed every two weeks by the Incident Management Point of Contact. Anomalies (denied accesses, unusual volume, unfamiliar IP) trigger the incident response plan.

10. Incident Response

Our incident response plan covers six phases:

  1. Detection — CloudWatch alarms, GuardDuty, manual reports to the IMPOC.
  2. Triage — severity classified within 1 hour.
  3. Containment — revoke credentials, isolate affected systems, snapshot evidence.
  4. Notification — Amazon notified within 72 hours per the SP-API Data Protection Policy; regulators per applicable law (Indian DPDP Act); affected users via email.
  5. Eradication & Recovery — patch root cause, restore from clean backup, verify integrity.
  6. Post-mortem — written within 7 days, distributed to leadership and incorporated into the runbook.

Tabletop exercises against this plan are run at least annually.

11. Your Rights

Where applicable Indian or other data-protection law grants you rights of access, rectification, erasure, restriction or objection in relation to personal data we hold about you, you may exercise those rights by contacting us at the address in section 14. We respond within 30 days. Note that the Application is an internal seller tool — buyers’ primary point of contact for buyer rights remains Amazon itself, since Amazon is the controller of buyer-side data.

12. Children

The Application is an internal business tool not directed at children. We do not knowingly collect data from children under 18. If we learn that we have inadvertently collected such data we delete it promptly.

13. Changes to This Policy

We may update this policy as the Application or our controls evolve. Material changes are reflected in the “Last updated” date at the top of this page. The current version is always reachable at this URL.

14. Contact

Incident Management Point of Contact (IMPOC):
Lokesh — lokesh@experiences.digital · +91 98997 97123

Mailing address:
Ruver
experiences.digital, Floor 5, NH-8, Ambience Island, DLF Phase-3, Sector 24, Gurugram 122002

For Amazon-related security incidents, we additionally notify security@amazon.com within 72 hours per Amazon’s Selling Partner API Data Protection Policy.

Ready to grow on every channel?

Free growth audit. Five minutes. Connect your store and marketplaces and see exactly where you’re leaving revenue behind.