Trust center / Privacy policy

Privacy policy for requirement handling

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

Kanwer Polytex collects only the information needed to review, route, and retain a dyed-yarn requirement within the website workflow.

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.

Captured fields

Identity and requirement details

Name, company, email, optional phone, product details, and the buyer's requirement are collected through the form.

Workflow purpose

Review, delivery, and recordkeeping

Submitted data supports requirement review, duplicate suppression, internal notification, and request traceability.

Operational processors

MongoDB, Resend, and Google reCAPTCHA

The live pipeline stores lead records, schedules internal notifications, and verifies anti-abuse signals through named service providers.

Requirement data received from the form

The website receives the information a buyer chooses to provide so the submitted requirement can be understood without guesswork.

Identity details such as name, company, email address, and optional phone number.
Requirement fields such as product category, product sub-category, product type, reference denier or count, shade reference, estimated quantity, target timeline, and delivery or visit details.
The free-text message that explains the need in the buyer's own words.
Operational anti-abuse signals associated with the submission, including hidden-field checks, verification outcomes, request identifiers, and hashed network metadata used for review.

How requirement data is used

Submitted data is used only to run the website contact workflow and support direct follow-up on the dyed-yarn requirement.

Validate the request and confirm that the payload matches the accepted website form contract.
Route the requirement to the internal handling path with enough context for the first review.
Suppress repeated or abusive submissions using duplicate-detection and anti-abuse controls.
Maintain request-level traceability for operational follow-up and website governance.

Processing path and service providers

The current contact-form implementation validates form data at the API route, stores the resulting lead record in MongoDB, and schedules internal notification delivery through Resend after persistence. Bot-verification checks rely on Google reCAPTCHA in the production intake path.

MongoDB stores the structured lead record together with operational fields such as request ID, notification status, and hashed network metadata.
Resend is used for internal email delivery after the lead is stored, with delivery state retained for operations traceability.
Google reCAPTCHA is used to verify browser-issued anti-bot tokens before a submission is accepted in production.

WhatsApp handoff and analytics

WhatsApp links open outside the secure form workflow, so buyers should treat WhatsApp as a direct communication handoff. Website analytics are limited to funnel intent and do not intentionally collect buyer-identifying details.

WhatsApp CTA events may record route, CTA location, broad product category, product type, denier or count, treatment interest, or funnel stage.
Analytics payloads must not include names, email addresses, phone numbers, WhatsApp numbers, shade notes, free-text messages, or full WhatsApp prefill messages.
Contact-form success events are tracked only after a successful submission and use product fields rather than personal fields.
The website does not provide shade-image upload because physical samples, approved shade codes, or shade-card references are safer for shade judgement.

Company profile request

The current company-profile flow offers both an approved PDF download and a WhatsApp request path for buyers who want the latest profile routed into a sourcing discussion.

Only approved company-profile collateral should be exposed through the public website.
A profile request or approved profile download may be measured as a CTA event, but the event payload must not contain buyer identity or message text.
Profile collateral must not be presented as proof of clients, certificates, export history, awards, testimonials, or commercial terms unless those claims are approved in the public claims checklist.

Retention, updates, and questions

Requirement records are retained according to operational review and website-governance needs. If a buyer has a question about a submitted request, the official contact route should be used so the request can be reviewed against the correct context.

Use the official email for policy or request-specific follow-up.
Reference the request ID from the submission response whenever available.
This policy can be updated as the website workflow or operating controls change.