One company, one space
Each customer has its own subdomain and its own data. No query crosses the company boundary.
Security and privacy Each company sees
Each company sees
only what belongs to it
This page explains what bFocus does to protect your data and your customer’s — no invented badges and no promise we cannot keep today.
- Isolation per company
- Identity verified by signature
- Per-user data export
Access Who gets in, and
Who gets in, and
how far they go
Passwordless login
Access by a code sent over email or WhatsApp, with a 30-day session. A password nobody stores is a password nobody leaks.
Roles and departments
Five roles and per-department visibility define who sees the whole queue, who sees only their own and who administers. In Mesa, the area puts each person's work first without hiding the rest.
Confirmed approvals
Approving or rejecting a request takes a code sent at that moment, and a single rejection is enough to block it.
A record of what changed
Ticket, task and approval events are stored with author and timestamp.
Confidential comments
Sensitive content only appears after the person confirms with a code, even when already signed in.
Asking for a code reveals no one
The sign-in screen shows the Cloudflare badge before it asks for the access code. The answer is the same with an account or without one, down to how long it takes: nobody finds out by trial which addresses get into your company.
Verified identity Your server says
Your server says
who is who
This is the mechanism that keeps customer A from seeing customer B’s ticket in the widget, in the native app and in the SDKs. Simple to implement and hard to fool.
- Your backend signs the user + company pair with a secret key (HMAC)
- The signature is checked on every request and lasts 7 days — your server issues a new one when it expires
- Rotating the secret invalidates the old signatures, with a 7-day transition so you can catch up
- An invalid signature is refused. With the “require verified identity” option on, a session without a signature does not get in — a widget created today starts with it already on
- The same applies to the web widgets, the native packages and the server calls
- The public key only opens the widget; with verified identity on, it reads nothing without your server’s signature
- The server key has per-resource scopes, an optional IP list and immediate revocation
How to do it
The verified identity guide shows how to calculate the v2 signature in Node, Python, PHP and other languages, with an example ready to copy.
The public door The widget is open,
The widget is open,
what goes through it is not
The publishable key sits in your site’s HTML. These locks hold even when the session arrives without a signature.
Without a signature, each browser sees only its own
An unsigned session shows the tickets and chats that browser opened, and nothing else. For the person’s whole list, turn verified identity on.
Without a signature, records are only created
What the page sends creates the customer and the person when they do not exist yet. It does not rename an existing record or move the person to another company.
Only files uploaded through the widget
A ticket accepts the file the widget itself uploaded, from the same company and the same user. The name, the type and the address come from what we stored.
A ceiling per IP and per company
Opening a ticket, commenting, chatting, uploading and getting an AI answer are capped per user, per IP and per company. Inventing a new user on every call does not get past it.
The root domain covers the subdomains
The browser reports the page address, so the widget only opens on the domains you register. Register the root domain and the subdomains come with it: https://customer.com already allows app.customer.com and shop.customer.com. The scheme has to match — https does not cover http — and so does the port, when you declare one.
The secret key stays on your server
The integration API is server to server and checks no domain: a server call carries no origin to check. The secret key never goes to the browser. When your front end needs the data, your company’s backend is the one that calls the API.
Proof of a human browser
The widget that answers at your site’s front door runs a Cloudflare challenge (Turnstile) the visitor does not see — the little box only shows up if Cloudflare gets suspicious. Whoever passes gets a short session, tied to your company and capped in uses, so nobody solves one challenge and reuses it in a bot. Whoever does not present the proof is refused with a 403 — and if Cloudflare is down, the request passes on purpose, so a third party cannot take your login down.
Whoever was refused lands in a queue
A domain refused at the widget, or an address refused on an API key, becomes a line under Company › Integrations › Authorizations: the address exactly as it arrived, how many attempts and when the last one was. Releasing it is one click, with no typing — no more registering www instead of the apex. Only an administrator releases it, and the screen warns that the address showed up on its own, recommending none of them.
Operations What holds
What holds
when something goes wrong
Backups are easy to promise and hard to verify. Here is what runs today, with the date of the last rehearsal.
A daily copy outside DigitalOcean
Once a day, a pg_dump of the database goes out encrypted with AES-256-GCM, streaming straight into S3-compatible storage at another provider. Copies are kept for 30 days. The managed database backup lives in the same account as the database; this copy is what is left if that account goes down.
Restoring has been rehearsed
With no encryption key, nothing is uploaded — and a failed run raises an alert for the people who run the platform. The decryption script is versioned alongside the code, and the restore rehearsal was done on 21 September 2026: the file was decrypted and read by pg_restore.
Routines run away from your chats
SLA, WhatsApp, AI, reports and the database copy run in a process separate from the API. If a heavy routine blows the memory, that process goes down and comes back up — not the API with every chat open.
Monitoring that does not take your data
Errors go to Sentry with no request body, no personal data and none of the code’s local variables: what arrives is the exception, the stack and the route. And a deep check answers with an error when the routine process stops beating.
LGPD Personal data,
Personal data,
treated as such
Under the LGPD, Brazil’s data protection law, the company that subscribes is the controller of its customers’ data; bFocus is the processor. What we offer so you can play your part:
- Export of a user’s data by the administrator, with a record; deletion on request, through support
- Articles generated from tickets come out with sensitive data masked
- Hardened inbound email: sender checked, replies only from people on the ticket and executable attachments blocked
- Audience measurement on this site only after you accept it — and no tracking inside the widget
- A compliance panel for what the SAC rules, Brazil’s consumer service regulations, and the LGPD require, including deadlines and access to a human
Where the data lives
DigitalOcean infrastructure in the United States (San Francisco region), with a managed database, backups and encrypted connections. The international transfer is covered in the contract, as the LGPD requires.
AI and your data The conversation goes to
The conversation goes to
the provider you chose
The key is yours
bFocus does not supply AI. Text sent to the model travels under the contract your company has with its own provider.
We do not train models
We train no model on your data, and we never use one company’s content to answer another.
A cap checked before spending
The limits in reais are checked before the call. When the cap is reached, support carries on with people.
No AI on our own account
Every AI call runs on your company key: the conversation, the summary, the classification and the vectors behind search by meaning over the base. bFocus does not supply AI, with no asterisk. Without a key that generates vectors, the base carries on with text search.
Questions about security
Do you look at my company data?
Only when you ask for help and authorize it, to investigate a specific problem. There is no content scanning.
Do you have ISO or SOC 2 certification?
Not yet. We would rather spell that out than display a badge we do not hold. What exists today is described on this page, and the page changes when reality does.
Can I erase everything if I leave?
Yes. When you close it, the account is deactivated and the data is deleted on request. Before that, you can pull reports and take the data out through the API.
Does the widget use cookies?
It uses no tracking cookies. It keeps the conversation session in the local storage of your customer’s browser, and that only serves to keep them from losing the history when the page reloads.
Still have a security question?
If your technology team needs details, we answer at whatever technical level they ask for.