Skip to main content

Privacy policy

Privacy policy for requirement handling

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

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.
  • Estimated monthly tonnage of dyed yarn to be purchased from Kanwer and destination country help us review bulk and export supply requirements.
  • The submitted enquiry may include a landing-page path, referring website name and campaign labels. These help us understand how the enquiry reached us; names, contact details and written requirements are not placed in this source metadata.
  • 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. Existing hosting analytics measure page use, performance and broad enquiry actions. Optional Google Analytics, when configured, loads only after the visitor allows it through Analytics preferences. Declining it does not affect the enquiry form.

  • 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.
  • Analytics URLs omit query strings and fragments. Campaign labels must not contain buyer contact details; free-text requirements and monthly allocation details stay in the internal lead record rather than ordinary analytics events.
  • A visitor's Google Analytics choice is remembered in the browser and can be changed through Analytics preferences. When allowed, campaign context may be retained in session storage for up to 30 minutes after the last page visit, and available advertising click identifiers may accompany the submitted enquiry. Declining analytics removes stored campaign context and prevents further optional Google measurement.
  • 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

Download the company profile or request it through WhatsApp when discussing a sourcing requirement.

  • The company profile introduces our yarn range and manufacturing capabilities. Ask our team for documentation relevant to your application.
  • Profile requests and downloads may be measured to understand how the website is used. These events do not include buyer identity or message text.
  • Product specifications, documentation and commercial terms for an order are confirmed separately with our team.

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.

Your next production run

Questions about a submitted requirement?

Use the official contact route and include the request ID when available so the privacy question can be reviewed against the right record.

Contact our team