Trust center / Security practices

Security practices for the contact form

Name: Kanwer Polytex
Address: Bhiwandi, Maharashtra, IN
Telephone: +91 7021872923

The Kanwer Polytex website protects the contact route with validation, anti-abuse controls, and request-level traceability before a buyer requirement reaches internal handling.

Privacy policy

What the site collects from a buyer requirement and how it supports review.

Security practices

How the contact form checks submissions and filters abuse.

Terms of use

How the yarn range, website content, and buyer enquiries should be used.

Route checks

Payload validation before processing

The lead API checks content type, payload size, JSON structure, and field-level validity before a requirement can enter the workflow.

Abuse controls

Rate limiting, honeypot, reCAPTCHA, and duplicate locks

The intake surface uses layered controls to block spam bursts and repeated submissions without weakening the operator workflow.

Stored signals

Request IDs, hashed IPs, and notification state

Each accepted requirement is stored with the operational metadata needed to trace persistence and delivery outcomes.

Entry protection on the lead route

The lead endpoint rejects malformed or obviously invalid traffic before business logic runs. This keeps the contact path explicit, auditable, and harder to abuse.

Requests must use the expected content type and stay within the configured payload size limit.
The raw request body is parsed explicitly and rejected when JSON is malformed or empty.
Server-side schema validation checks the complete lead payload, including dependent product fields.
A hidden honeypot field is checked before the submission can proceed deeper into the workflow.

Bot and duplicate suppression

The intake flow is designed to reduce bot traffic and repeated bursts without blocking the path for legitimate buyers.

Google reCAPTCHA verification is enforced by the server-side lead route in production-capable environments.
Rate limiting is applied before processing to reduce repeated submission abuse.
Email addresses are normalized and requirement content is fingerprinted so exact repeats can be identified.
A short-lived submission lock helps suppress repeated bursts while preserving clean retry behavior when persistence fails.

Stored operational record discipline

Accepted requirements are stored with the operational context needed to audit the route, trace notification delivery, and review suspicious patterns.

Each record carries a request ID so the submission can be traced across intake, persistence, and notification steps.
IP addresses are stored as hashes rather than raw values for operational review and abuse analysis.
Normalized email values and requirement fingerprints are stored to support duplicate detection.
Notification state is written back to the lead record so delivery success or failure remains visible to operators.

Operational review and escalation

Security-related questions or suspicious website behavior should be reported through the official contact route so the request can be reviewed against logs, request IDs, and stored notification state.

Use the contact page or official email for security-related questions tied to a live request.
Include the request ID when referencing a specific submission.
These practices can evolve as the website's intake stack and operational safeguards are refined.