Privacy Policy

1.Who we are, and who this policy is for

SajiloMitra is a customer-conversation platform operated by TODO: registered company name, registered at TODO: registered address. Our registration details appear in the footer of every page on this site.

This policy covers two very different groups of people, and it is worth being clear about which one you are.

• Businesses and their staff. If you signed up, or a colleague invited you into a workspace, we hold an account for you and we decide how that account data is handled.
• The customers of those businesses. If you messaged a shop on WhatsApp, Messenger, Instagram, Telegram or its website and that shop uses SajiloMitra, your message is stored in our system on that shop’s behalf. The shop decides what is collected and why; we hold it for them and act on their instructions. If you want your messages removed, the shop is usually the right first contact — but you can also write to us directly and we will help. See Data Deletion Instructions.

2.What we hold about people who work for a business using SajiloMitra

For each person with a SajiloMitra account we store:

• Name and email address.
• A one-way hash of the password (BCrypt). We never store or have access to the password itself.
• An optional profile picture address.
• Workspace membership and role: owner, admin, agent or viewer.
• Sign-in sessions, held as a hash of the session token with its expiry — never the token in readable form.
• Invitations you sent or received, with the email address invited and its expiry.
• A record of your work in the product: which conversations are assigned to you, which messages you sent, and when you last read a conversation.

We do not record your IP address or browser user-agent string in any database table. A visitor’s address is used momentarily, in memory, to rate-limit the website chat widget, and is not written down.

3.What we hold about a business’s customers

When someone messages a business through a connected channel, we create a customer record for them. What lands in it depends entirely on what the channel gives us:

• WhatsApp. The customer’s phone number — it is the account identifier on that channel — and the display name they have set on WhatsApp.
• Telegram. The Telegram account id, the first and last name on the account, and the @username if one is set.
• Messenger and Instagram. Only the opaque account id Meta gives us (a PSID or IGSID). We do not look up the person’s name or profile picture, so a new customer on these channels arrives with no name at all until a member of the business types one in.
• Website chat. A session identifier for the browser. No name, unless the visitor gives one.

A business can also add or edit a customer’s name, email address, phone number, preferred language and notes by hand, and can attach tags.

Where the AI assistant has read a conversation, we may additionally store what was being asked for — the kind of purchase, product name, quantity, budget range and delivery location. These are stored as fields on the customer record. The assistant can only fill a field that is blank: a value a person typed is never overwritten.

4.Messages and files

The text of every message in a conversation — inbound and outbound, whether written by a person or generated by the assistant — is stored in our PostgreSQL database, together with its channel, direction, timestamp, delivery status and the message identifier the channel gave it.

Files and images sent through Telegram are stored in our object storage (a MinIO/S3-compatible store), under a path that is scoped to the business that owns them. They are not public: nothing in the store can be fetched by URL. A file is served only to a signed-in member of that business, through a link that our servers mint on request and that stops working after five minutes.

Photos and files sent over WhatsApp, Messenger and Instagram are currently not stored at all — that part of those channels is not built.

5.The AI assistant, and what leaves our servers

This is the section most worth reading carefully, because it is where conversation content is sent to a company that is not us.

What is sent, and when

When the assistant generates a reply, the following is sent to an AI provider over the network:

• Instructions the business itself wrote: the assistant’s name and tone, the business name and description, opening hours, standing instructions and escalation rules.
• Extracts from the business’s own knowledge-base documents that the system judged relevant to the question.
• Live product, price and stock information read from the business’s own storefront, when the conversation is about buying something.
• The recent conversation text, word for word — up to the last 20 messages. When someone asks the system to extract lead details from a thread, up to the last 60 messages are sent.

We do not attach the customer’s stored name, phone number, email address or channel identifier to that request as separate fields. But a phone number, address or email a customer typed into the chat is part of the message text, and message text is sent.

Which provider receives it

A business can point SajiloMitra at its own AI provider account, using its own API key. In that case the traffic goes to the provider it chose and our own key is not used at all. A business that does not configure one uses the provider this installation is set up with, under our account. Either way, an API key a business supplies is stored encrypted and can never be read back out of the product.

What does not leave

The step that turns documents and questions into search vectors runs on our own infrastructure, in a container we host. That text is not sent to an outside embedding service.

We also keep a per-request record of how many tokens a generation used and its estimated cost, so a business can see what its assistant is costing.

6.Ordering, and your own storefront

When the assistant takes an order, the order is created in the business’s own storefront, not in SajiloMitra. We hold no product catalogue, no inventory and no order table. To create that order we send the storefront the delivery details the customer gave in the conversation — typically name, email address, street and city, plus a phone number if the customer volunteered one.

No payment is taken in the chat. The assistant is instructed that orders are cash on delivery and is forbidden from asking for card or bank details. We never see, store or transmit payment credentials.

7.Text messages

Where a business has configured an SMS gateway, sending a message hands the recipient’s phone number and the message text to that gateway: either Sparrow SMS, or httpSMS, which relays through an Android handset the business itself controls.

A business keeps an opt-out list. A number on that list is refused before any gateway is contacted.

8.Cookies, browser storage and tracking

We run no analytics or advertising trackers. There is no Google Analytics, no Meta pixel, no session recorder and no third-party tag of any kind on this site, in the application, or in the chat widget.

The application sets exactly one cookie:

• sm_refresh_token — keeps you signed in. It is marked HttpOnly so no script can read it, restricted to the single server path that handles sessions, and sent over HTTPS only in production. It is deleted when you log out.

Your short-lived access token is held in the page’s memory only and is never written to a cookie or to browser storage. Layout preferences — whether the sidebar is collapsed, how wide you dragged the inbox panes — are kept in your browser’s local storage and never reach us.

The website chat widget sets no cookie. It keeps a session token in the local storage of the site you are visiting, so that a conversation continues if you reload the page.

9.Who else sees this data

We do not sell data, and we do not share it for advertising. It reaches these parties, for these reasons:

• The messaging platforms. Meta (Messenger, Instagram), WhatsApp and Telegram necessarily see messages sent through them; their own privacy terms apply to what they hold.
• An AI provider, as described above — either the business’s own or ours.
• An SMS gateway — Sparrow SMS or httpSMS — where a business sends a text message.
• The business’s own storefront, when an order is placed.
• An email server, for invitations and rule notifications sent to colleagues.
• Our hosting provider: TODO: name the hosting provider and the country it runs in.

We may also disclose data where we are legally required to, and we will tell the affected business unless we are forbidden from doing so.

10.How it is protected

Every business’s data is separated at the database level: a query for one workspace’s conversations cannot return another’s, and that separation is covered by an automated test suite rather than by convention.

• Passwords are stored only as BCrypt hashes; session tokens only as hashes.
• Credentials a business gives us — AI provider keys, SMS gateway credentials — are encrypted at rest and are never returned by any interface.
• The chat widget runs only on website addresses the business has listed, behind a site key it can rotate at any time.
• Incoming webhooks from Meta are rejected unless they carry a valid cryptographic signature.
• Stored files are never publicly addressable; access goes through a signed link that expires in five minutes.
• We keep an append-only audit log of significant administrative actions — role changes, member removals, channel connections and disconnections, site-key rotations, assistant changes and workspace suspensions — recording who did it, to what, and when.

11.How long we keep it

We must be straightforward about this: there is currently no automatic deletion. No scheduled job removes messages, conversations, customer records, audit entries or closed accounts after any period. Data stays until somebody deletes it.

What that means in practice today:

• A business can delete its knowledge-base documents, tags, automation rules, channel connections and its storefront connection from within the product, and doing so removes the underlying data.
• Removing a colleague removes their access immediately. The messages they sent remain in the conversation history, no longer attributed to them.
• A customer who has never sent a message can be deleted from within the product. A customer who has sent one cannot yet be — the product refuses, rather than silently orphaning their conversation. Erasing them is a manual operation we perform on request, and the Data Deletion Instructions describe exactly how to ask and what happens.

Intended retention periods, once the automatic deletion described above is built: account data TODO: account data retention period, messages and media TODO: message and media retention period, audit logs TODO: audit log retention period.

12.Your choices

You can ask us to:

• tell you what we hold about you;
• correct something that is wrong;
• delete it — see Data Deletion Instructions;
• stop sending you text messages, which we do by adding your number to the business’s opt-out list.

Write to TODO: privacy email address. We will ask for enough information to be sure it is really you before we act — we are not going to delete a stranger’s conversation history on an unverified request.

There is currently no self-service data export. A copy of what we hold is produced by hand on request.

13.Children

SajiloMitra is a tool for businesses and is not directed at children. We do not knowingly create accounts for anyone under 16. If a business’s customer turns out to be a child and their guardian asks us to erase their messages, we will.

14.Changes to this policy

When we change something material here we will update the review date at the top of this page and tell workspace owners by email. Continuing to use SajiloMitra after that means the updated policy applies.

15.Contacting us

Privacy questions and requests: TODO: privacy email address.

Complaints go to our complaint officer, TODO: complaint officer name, on TODO: complaint officer phone number. Everything else: our contact page.