Skip to content
SellerSaarthiSellerSaarthi — home
Legal · Shreesoftic / SellerSaarthi

Security

How we protect your Amazon Data — and how security researchers can responsibly report issues to us.

Last reviewed ·
26 April 2026
Effective ·
26 April 2026

1. Summary of security practices

  • Encryption at rest. AES-256 via AWS RDS native encryption and S3 SSE-KMS.
  • Encryption in transit. TLS 1.2 or higher for every public endpoint.
  • Key management. Refresh tokens and sensitive credentials are encrypted with AWS KMS customer-managed keys and never logged.
  • Access controls. Role-based access. Access to Amazon Data is strictly on a need-to-know basis within the founding team. Audit trail on every privileged action.
  • Safe-write rails. Every Amazon API write goes through our SafeWriter service, which enforces a circuit breaker, an actions_log audit entry, and a hard cap that no single automated action depletes more than 5% of the customer's daily budget.
  • Monitoring. Sentry for error tracking. PagerDuty for on-call alerts. API response codes, latencies, and rate-limit headers logged with timestamps.
  • Data residency. Primary storage in AWS ap-south-1 (Mumbai). Data transfer to other regions only via encrypted backups under safeguards.

2. Vulnerability disclosure process

If you believe you have found a security issue in SellerSaarthi:

  • Email security@sellersaarthi.com.
  • Optionally encrypt your report with our PGP key: /pgp-key.txt.
  • We acknowledge within 48 hours.
  • We aim to provide an initial assessment within 5 business days.
  • We credit responsible disclosers in the Hall of Fame below, with permission.

3. Scope

In scope: our production domains (sellersaarthi.com, app.sellersaarthi.com, staging.sellersaarthi.com), our public APIs, our LwA callback endpoints, and our published clients.

Out of scope: third-party services we use (Amazon, AWS, Razorpay, Clerk, Anthropic, PostHog, etc.); social engineering or physical attacks on the founding team; UI/UX issues with no security impact; missing rate-limits on clearly non-sensitive endpoints.

4. Safe harbour

We will not pursue legal action against good-faith researchers who:

  • Follow this disclosure process.
  • Do not access more data than necessary to demonstrate the issue.
  • Do not publicly disclose the issue before we have had a reasonable opportunity to remediate.

5. Hall of fame

We are grateful to the following researchers for responsibly disclosing issues:

(The wall is currently empty. If you are first, your credit goes here.)

6. security.txt

An RFC 9116-compliant security.txt is published at /.well-known/security.txt.

Effective date: 26 April 2026.