Built to verify addresses, not to quietly become another data risk in your stack.

How the platform is designed

Sovolink separates public marketing pages, authenticated dashboard access, and CMS access. Verification logic runs through the API layer and is guarded by quota checks, account verification checks, and session-aware authentication.

The service is intentionally narrow in scope. Sovolink validates email deliverability signals through syntax checks, DNS/MX checks, SMTP handshakes, and provider heuristics. It is not a campaign sender, SMTP relay, mailbox host, or contact database broker.

That design matters for security because it keeps the attack surface tighter. The platform handles verification requests, results, billing state, and account access rather than broader messaging workloads.

How we handle data

Account data includes your name, email address, plan metadata, quota usage, and session information needed to operate the dashboard and API.

Verification inputs are processed for deliverability analysis. Sovolink is designed to avoid indefinite plaintext retention of submitted email addresses once the verification lifecycle is complete. Where persistent records are needed for abuse prevention and quota enforcement, hashed identifiers are preferred.

Bulk jobs retain the original uploaded structure long enough to generate downloadable results and preserve auditability for the account that created the job. Those records remain scoped to the authenticated account and are not used for any unrelated purpose.

Authentication and access control

User dashboard routes and CMS routes are protected behind authenticated access. Access tokens are validated server-side, sessions expire, and stale or expired tokens are cleared on the client before protected experiences continue.

Administrative access is isolated from the standard user dashboard. CMS authentication uses a separate admin auth flow and separate stored session state from the primary user application.

Sensitive dashboard and admin APIs are not intended for anonymous browser access. They require authenticated credentials and return authorization failures when tokens are invalid, expired, or missing.

Billing and payment boundaries

Subscription billing is handled through Razorpay. Sovolink does not store raw card numbers or payment instrument details on its own application servers.

The application stores subscription identifiers, quota state, and billing status necessary to enable plan enforcement and subscription lifecycle handling.

Payment webhooks are used to synchronize subscription state so the product can update access and quota limits without exposing payment secrets in the client application.

Operational controls

The API uses rate limiting around sensitive endpoints such as authentication and public verification. This helps reduce brute-force, abuse, and accidental overload.

Application sessions are tracked server-side so access can be invalidated instead of trusting browser state alone.

Error handling, route scoping, and quota enforcement are applied at the API layer to reduce the chance that a client-side state issue becomes a silent authorization issue.

Security limits and shared responsibility

No internet-facing application can honestly promise zero risk. Email verification depends on external SMTP and DNS infrastructure that can be throttled, rate-limited, or behave unpredictably.

Customers remain responsible for their own endpoint hygiene: strong passwords, device security, safe API key handling, and lawful use of verified data.

Sovolink reduces operational and data handling risk around list hygiene. It does not replace your own access management, vendor review, or legal compliance process.

Incident reporting and disclosure

If you believe you found a security issue, report it privately rather than disclosing it publicly first. Include reproduction steps, affected routes, and any logs or screenshots that help verify the issue.

For responsible disclosure, contact the team directly so the issue can be triaged and resolved before wider publication.

Security reports can be sent to security@sovolink.com. If the issue is customer-data related, include your account email and the affected environment so triage can begin faster.

If you found a vulnerability, email the team directly with steps to reproduce, affected routes, severity estimate, and any logs that help confirm impact.