Security, access and customer-data handling
What is implemented today, what is project-specific, and what we do not claim.
HTTPS & transport
The public Freshtiq website and portal are served over HTTPS. Credentials, OTPs and payment-card details are not requested through public enquiry forms or the website chatbot.
Server-side validation
Lead and chat APIs validate and limit incoming data server-side. Public endpoints use rate limits and input-size controls; customer-facing code does not contain service credentials.
Owner access
Owner/admin records are handled through authenticated portal routes. Public visitors can submit enquiries but cannot use public pages to read or edit stored lead records.
AI data handling
The current website consultant answers from server-side approved Freshtiq knowledge and deterministic business rules. It is designed not to ask visitors for passwords, OTPs or payment-card data.
Backups & restore
Portal data is backed up on the server and restore integrity is tested. Project-specific customer backup frequency, retention and responsibility are written into the deployment scope.
Third-party services
Projects may use hosting, messaging, analytics, payment, AI or other providers only when the approved scope requires them. Provider ownership, recurring fees and data flow are documented before launch.
What we do not claim
Freshtiq does not present this page as a certification, penetration-test report or guarantee that software can never be compromised. Security controls depend on each project's architecture, hosting and integrations.
Responsible reporting
If you believe a Freshtiq public system has a security issue, do not access or modify other users' data. Send the affected URL, steps to reproduce and evidence to hello@freshtiqautomation.com. See the technical vulnerability-reporting policy.
Need a security requirement in your project scope?
Tell us the data, users and integrations involved. Security responsibilities can be made explicit in the written proposal.
Request Free Consultation