Privacy Policy

1. Who we are and what this policy covers

KARODIAL is operated by Avycore Tech Private Limited. This Privacy Policy explains the handling of personal information through karodial.com, its account features, project enquiries, support conversations and related development services. It applies when you explore designs, discuss a website or Android/iOS application, communicate with our team or use an available integration. It explains our own activities; it does not automatically become the privacy policy of a customer website that we build.

A customer's business decides how its own customers' information is used, subject to the arrangements for that project. Read this document with our Terms of Service and any written project agreement. A project-specific data-handling arrangement can add detail about access, instructions, delivery and deletion, but cannot remove rights that applicable law gives you. You can ask about a particular feature before sharing information. Our privacy contact is support@karodial.com; identify KARODIAL and the relevant account or project in your message.

2. Information you choose to provide

Information supplied through our forms can include your name, email address, country calling code, telephone number, business name, message and requested service. An enquiry may also contain your selected design, plan, budget discussion or explanation of the features you need. These details help us understand the request and contact the right person. Please provide only information relevant to that purpose. A short description of a business requirement is usually enough for an initial conversation; customer databases, government identity documents and private financial records are normally unnecessary at this stage.

If you describe another person, make sure you are entitled to share their details and tell them about the relevant use. Providing a telephone number does not, by itself, authorise unrelated promotional campaigns. Optional information is your choice, although withholding information essential to a specific request can prevent us from answering accurately or carrying out the requested work. Contact us to correct an accidental or excessive submission.

3. Accounts, sign-in and profiles

When you create or access an account, we handle the identifiers and authentication information needed to recognise you and protect your session. Google sign-in through Firebase can provide an account identifier, name, email address, verification information and profile image where supplied by the provider. We do not receive your Google password. Information available depends on the sign-in method and permissions involved. Where our own password authentication is used, such as administrative or staff access, passwords are stored as hashes rather than readable passwords.

Account records can include creation time, role, access status and related security events. A minimal profile helps associate an enquiry with the correct customer and avoids asking for the same contact information repeatedly. Please keep your email address accessible and your profile accurate. Signing out ends your application session but does not delete your account, enquiry history or records held by the sign-in provider. Account deletion and provider-account deletion are separate actions.

4. Design selections and enquiry records

An explicit design or plan selection can be remembered during your browsing session so that the enquiry you choose to send contains the intended reference. A random session reference can connect a draft selection with an account after sign-in. Sending an enquiry creates a business record containing the details you submitted and the selected design or plan, where applicable. A generic contact request is intended to remain a general request rather than silently adopting an old design selection.

Our team can record follow-up notes, approach dates, enquiry stages, project conversion and project progress to manage the relationship. A history entry may identify the authorised staff member who made a change and when it occurred. These records help avoid lost requests and explain previous decisions. They are not public catalogue content. Contact us if a selection or note is inaccurate; some historical records may need to be preserved with a correction rather than silently rewritten, especially where a payment or dispute is involved.

5. Payments, invoices and transaction information

Where online checkout is offered, payment processing uses Razorpay and the payment methods made available by that provider. Opening checkout can share the payer's name, email address, telephone number, order reference and amount needed for the transaction. KARODIAL can retain order identifiers, payment references, base amount, applicable tax, verification results and payment status for reconciliation, support and accounting. We do not store your complete card number, card security code or UPI PIN in our application.

Enter payment credentials only into the legitimate payment interface, and never send them to our public contact form or chatbot. A bank statement or payment screenshot can contain unrelated information; redact details that are not needed when seeking help. Transaction records may need to remain after account closure to meet accounting requirements, investigate an incorrect charge, handle a refund or respond to a dispute. Payment-provider retention and verification checks are governed by that provider's notices and applicable requirements, alongside our own handling of the limited records described here.

6. Technical information and activity logs

Ordinary website requests can reveal an IP address, browser and device information, requested page, request time and technical error information to our hosting infrastructure. Application activity can also record account identifiers, sign-in attempts, page visits, form actions and administrative changes where those events are logged. Some login-protection records use hashed identifiers or IP-related values rather than the original value; this does not mean every infrastructure log is anonymised.

These records help investigate failures, protect accounts, identify abusive requests and understand how a reported problem occurred. Avoid placing sensitive information in a page URL or search parameter because URLs can appear in browser history and request logs. Technical information is not a reliable proof of a person's identity or exact physical location. Access to non-public activity records is intended for authorised operational purposes. If a support request needs a screenshot or error message, share the minimum useful detail and remove passwords, access tokens and unrelated personal information before sending it.

7. Why we use personal information

We use relevant information to operate accounts, answer enquiries, understand requirements, prepare proposals, communicate about requested work and maintain project records. It can also support payment reconciliation, delivery coordination, customer assistance, security monitoring, misuse prevention and the handling of legal or accounting obligations. The purpose depends on the interaction: an email address supplied for an enquiry helps us answer that enquiry; a project brief helps us assess and perform the requested work.

We do not treat all information collected through the website as available for every possible business purpose. We do not sell or rent personal information. If a new use requires a separate choice or notice under applicable law, it should be addressed before that use rather than hidden within an unrelated transaction. Some processing is necessary for a requested service or a legal obligation, while optional features can be avoided. We explain meaningful limits when a request to stop processing affects an existing project, security record or mandatory retention requirement.

8. Support, email, telephone and SMS

We may contact you about an enquiry you submitted, information needed for a quotation, an active project, payment clarification, account security or a support issue. The appropriate channel depends on the details you provided and the nature of the request. Where SMS integrations are configured, service messages can include registration welcomes and contact-form acknowledgements. The availability of an SMS feature in a customer plan is not a statement that every visitor will receive a message.

Acknowledgements confirm receipt; they do not approve a project, guarantee delivery or replace a written agreement. Our internal notes may record the outcome of a call or follow-up so another authorised team member can continue helping you. Tell us if a contact detail is wrong or you prefer a different available channel. Requests to stop optional promotional communication do not necessarily stop essential messages about an existing account, payment, security concern or contracted service. We will distinguish these purposes when considering your request and the requirements that apply.

9. Approximate city greeting and your choice

Our greeting can use an IP-based city lookup from ipapi.is when the feature is enabled. That request exposes your IP address and ordinary connection information to the provider. Its response can include additional network or location fields, but the greeting uses the city and does not save the full response in our application database. This is not GPS tracking and does not ask for a device location permission. A VPN, corporate gateway or mobile network can produce an incorrect city.

The greeting is cosmetic and is not used as proof of residence, identity or service eligibility. The browser can cache the result in session storage for up to thirty minutes to avoid repeated lookups. You can disable future greeting lookups through the control below; the feature also respects the browser's Global Privacy Control signal. Disabling does not delete information already processed by the provider. Your choice is stored for this browser, so another browser or cleared storage can have a different setting.

10. Cookies and browser storage

First-party session cookies help maintain sign-in, protect form submissions against forged requests, remember an explicit selection and display confirmations. These are functional parts of the service; blocking them can prevent a login or enquiry flow from working. Browser storage is also used for particular interface choices, such as the city-greeting preference, its temporary city cache and catalogue return position. The WeBot widget can keep interface settings, including panel size, placement and its consent interface.

Authentication and payment providers may use their own cookies or storage during the features they supply. A browser request for a third-party resource can disclose connection information even before you interact with its interface. This policy does not promise that every external resource waits for a cookie banner. Use browser settings to inspect or clear storage, understanding that doing so can sign you out and reset preferences. Private browsing separates some local history but does not make requests invisible to hosting, network or service providers.

11. Chatbot, AI assistance and conversations

Our embedded assistant is supplied through WeBot. If you use it, the messages you enter and technical information needed to deliver the conversation can be processed by WeBot and the AI services configured for that assistant. A chat can reveal personal information even when there is no dedicated personal-data field, so share only what is needed to ask your question. Do not enter passwords, API keys, payment credentials, identity-document images, confidential customer records or private health information in public chat.

AI responses can be inaccurate and should not be treated as a private legal consultation, a binding quotation or a guaranteed project commitment. Avoiding chat does not prevent you from using our ordinary contact options. Provider retention, account controls and handling of AI inputs depend on the service and configuration; this policy does not promise universal zero retention or that no provider ever uses data for model improvement. Ask us to confirm suitable contractual and technical arrangements before providing confidential material for an AI-enabled project.

12. Service providers and necessary sharing

Our website depends on services that receive information relevant to their functions. Hostinger supplies hosting and related infrastructure. Google/Firebase supports authentication; Google Fonts supplies font resources. ipapi.is supports the optional approximate-city greeting. WeBot supplies the embedded assistant, and Razorpay supports checkout where offered. Email, SMS or project integrations may involve additional providers when configured for the requested service. Information shared should correspond to the task, rather than giving every provider a copy of every account record.

Providers may act on our instructions for some activities and independently for their own security, legal obligations or consumer-facing services. Their privacy notices explain those separate activities. A link to a provider does not make its practices identical to ours. Ask about a proposed integration before approving a project if your business has specific confidentiality, location or contractual requirements. We do not publish an enquiry as a testimonial or disclose a private project brief as catalogue content merely because you contacted us.

Provider privacy information:Firebase · Google · ipapi.is · Razorpay

13. Processing locations and external websites

Internet services can process information in locations different from where a visitor lives or where a project is delivered. Hosting, authentication, communications, AI and payment providers use their own infrastructure and operational arrangements. We do not promise that all information remains exclusively in India or in a single server location unless a specific verified project agreement provides that commitment. Tell us before sharing regulated or confidential material if your organisation requires a particular processing region or a restriction on international access.

Such requirements need to be assessed against the actual services involved. An external link takes you to a service with its own notices, account settings and legal responsibilities. Similarly, a customer's deployed website or app may use a different hosting or analytics arrangement from karodial.com. Reviewing this policy alone is not enough to evaluate that separate product. Where applicable law imposes conditions on transfers or disclosures, those conditions must be considered; using our website does not waive protections that cannot lawfully be waived.

14. Customer projects and development access

A development engagement can require access to a customer's hosting, repository, CMS, test account or third-party service. Agree the scope and a suitable transfer method before sharing credentials or datasets. Temporary, limited-access accounts are preferable to sharing an owner's permanent password. Where possible, use sample or masked data for demonstrations and testing rather than a production customer database. If production access is necessary, the project should identify the permitted purpose, authorised people and arrangements for returning or deleting materials after the work.

Customers remain responsible for having authority to disclose the data they provide and for giving their own users appropriate notices. Our own website policy is not a substitute for a processing agreement when one is needed. We do not automatically obtain permission to reuse private customer data for another client's project or a public demonstration. Removing our access from a customer's system is separate from deleting correspondence, invoices or other records we must legitimately retain about the engagement.

15. Android, iOS and webview project information

When discussing an app, we may need information about the existing website, intended users, sign-in flow, platform requirements, desired notifications and requested device features. A website address alone does not authorise access to its private administration area or its users' information. App permissions, analytics, push tokens, crash reporting and app-store disclosures depend on what is actually implemented for that project. This policy does not claim that every KARODIAL-developed app collects all of those categories.

A webview wrapper can still involve the underlying website's cookies, authentication and third-party requests, alongside native app behaviour. The app owner should have a product-specific privacy notice and accurate store declarations before release. Agree who operates the backend and who can access production data. If your project needs camera, microphone, location, contacts or other device permissions, discuss necessity and disclosure explicitly rather than treating those permissions as an automatic part of app development. Testing access should be limited and revoked when no longer needed.

16. Staff access and internal records

Authorised team members need access to relevant information to respond to enquiries and deliver work. Access can depend on role and assigned responsibilities. For example, business-development work can involve customer enquiries and follow-up while project progress may be visible without permission to edit it. Administrative, support, accounts and HR functions have different purposes; a role label does not make every record appropriate for every person. Staff-account records can include name, work email, assigned role, access status and authentication information.

Administrative changes and security events can be logged to support accountability and troubleshooting. The staff login is for authorised personnel and is not a public customer registration route. Customers should communicate account changes through established contact channels rather than asking an individual to bypass access controls. If a team member leaves or a project ends, access should be reviewed according to the systems involved. We cannot promise deletion of records that must remain for employment, accounting, security or dispute-handling reasons merely because a login is disabled.

17. How long information is kept

There is no single automatic deletion period for every account, enquiry, project, payment and security record. Retention depends on the reason the information exists, whether the relationship is active, applicable accounting or legal requirements and the need to resolve a complaint or protect a legitimate claim. An unsuccessful enquiry need not be treated in the same way as an invoice or an active project file. We consider whether the original purpose still requires identifiable information when reviewing a deletion request.

Some material may remain in backups until the relevant replacement cycle; restoration should not be used to revive information that should no longer be actively used. Copies you keep, materials delivered to you and information retained independently by external providers are outside a single application deletion action. Ask about the particular category and purpose if you need a clearer explanation for your project. We should explain a lawful reason for retaining necessary records rather than promise immediate removal of everything from every system.

18. Security precautions and incident concerns

Our application uses measures including HTTPS, protected sessions, password hashing where passwords are handled, access controls and safeguards against forged form requests. These measures reduce risk but do not make any website, email, third-party integration or internet transmission absolutely secure. Keep account credentials private, use secure devices and review the address of a sign-in or payment page before entering information. Staff and support should not need your Google password, card security code or UPI PIN to answer an ordinary query.

If you suspect account misuse, a leaked project credential or an unintended disclosure, contact support with the affected service and approximate time. Do not publicly post an exposed token or private dataset as proof. We will review the report, consider protective steps and address notification or reporting duties where applicable. The response depends on the incident, available evidence and the systems involved; this policy does not promise a fixed investigation outcome or absolute recovery of information already disclosed to an unauthorised person.

19. Access, correction, deletion and other requests

You can ask us about personal information associated with your account or interaction, request a correction, seek account closure or deletion, and raise concerns about its use or disclosure. Access to specific rights and the extent of a response depend on applicable law and the circumstances. Send requests to support@karodial.com with enough detail to identify the account and the information involved. We may ask for proportionate evidence of account control or authority to act for another person.

Do not send a password or excessive identity documents. We must also consider the privacy of other people, security information and records subject to a lawful retention requirement. Where a request cannot be fulfilled in full, we should explain the relevant reason and available next steps. Changes to records do not necessarily rewrite past invoices, audit entries or messages already delivered. We cannot close a Google account or erase a payment provider's independent records on your behalf through a KARODIAL account action.

20. Optional features, withdrawal and children

You can explore the public catalogue without creating an account, avoid the chatbot, use a general contact request and turn off the approximate-city greeting. Browser settings can limit storage, although essential features may then stop working. If information is being used on the basis of a permission you can withdraw, tell us which permission and activity you mean so we can assess the request and explain its effect. Withdrawal does not automatically invalidate processing already completed or erase records kept for another lawful reason.

Our account and paid-project services are intended for adults and authorised business representatives. We do not knowingly seek children's personal information through these services. A parent or guardian who believes a child supplied information should contact us with the relevant context, without sending unnecessary documents about the child. A project involving services directed at children needs a separate assessment of age-appropriate notices, permissions and applicable requirements; it should not rely solely on this general website policy.

21. Legal requests, business changes and safeguards

Information may need to be disclosed to comply with a valid legal requirement, respond to an authorised public authority, investigate fraud, protect safety or establish and defend legal rights. Such situations should be assessed for authority, relevance and the information actually needed. This is not a general permission to disclose every customer record whenever someone asks. If the business undergoes a genuine restructuring or transfer, related information may be part of the transaction, subject to appropriate confidentiality, applicable law and any required notices.

A new purpose that needs separate permission is not automatically authorised by changing a business name. This policy is intended to describe our practices, not to claim certification under every privacy regime or that every provision of a newly notified law is already in force. Applicable requirements and their commencement dates must be considered in the relevant circumstances. Nothing here removes a mandatory privacy protection or prevents you from approaching an appropriate authority or forum when the law allows it.

22. Policy updates, questions and grievances

The date at the top identifies this version of the policy. We may revise it when features, providers, legal requirements or our operating practices change. A material change that requires an additional notice or a fresh choice should be handled accordingly; simply changing a web page does not replace a permission required by law. For a privacy question, correction request, deletion request or grievance, email support@karodial.com and include “KARODIAL privacy” in the subject. Describe the relevant page, account or project, what happened and the outcome you seek.

Keep the first message focused and avoid attaching sensitive records unless necessary and an appropriate method has been agreed. We may need to clarify the request or verify your authority before disclosing personal information. If the first response does not address your concern, reply with the unresolved point so it can be reviewed. Our Terms of Service explain the general commercial relationship; this policy explains personal-information handling. Neither document limits remedies that applicable law makes available to you.