Privacy Policy

• Account: your name, email address and a hashed password. We never store the password itself.
• Your page: everything you put on it — handle, display name, description, avatar, links, offerings, prices, files and the knowledge the assistant answers from.
• Billing: your subscription status, plan and the last four digits and brand of your card. Full card numbers never reach our servers — they go directly from your browser to Stripe.
• Payouts: if you connect Stripe, we store your Stripe account id and whether it can take charges. Your identity documents and bank details are held by Stripe, not by us.
• Usage: how many assistant replies your page has generated in the current period, so we can count it against your plan.
• Technical: server logs, which include IP addresses, for security and debugging.

• Conversations: the questions asked and the answers given. The creator can read these in their dashboard — a visitor should treat a chat on a creator page as a message to that creator.
• What you submit: when you book, sign up, apply, enquire or buy, whatever the form asked for — typically name, email, phone and your own answers.
• Payments: if you pay, your card details go from your browser to Stripe and are processed on the creator’s own Stripe account. We store the payment’s id, amount and status — never the card.
• Analytics: page views and conversation counts. Our own analytics does not store your IP address. An address is combined with a secret salt and a one-way hash before it is written, which lets us count one person visiting twice without being able to work out who they are or look them up later. PostHog, the product analytics service in section 4, records which pages were opened and which buttons were pressed, and does receive an IP address — it uses it to derive a rough location and then keeps it. We do not attach a visitor’s name or email to it.

If you are a visitor, your relationship over what you submit is with the creator. They decide what to do with it; we hold it on their behalf. To have it removed, ask them — or write to us and we will pass it on.

• To perform the contract: running your page, answering questions, taking subscription payments.
• Legitimate interests: keeping the service secure, preventing abuse, and understanding how it is used in aggregate.
• Legal obligation: tax and accounting records.

We do not sell personal data, and we never will. We share only what these services need to do their job:

• Stripe — payments and subscriptions.
• xAI — generates assistant replies. It receives the creator’s page material and the conversation. We do not permit training on it.
• Cloudflare — serves the site and stores uploaded files.
• Resend — sends our email.
• Laravel Nightwatch — error and performance monitoring. When something breaks it receives the fault and where in the code it happened, along with how long requests and jobs took. Request bodies are not collected, passwords and session cookies are stripped before anything is sent, and there is no session recording anywhere on the site.
• PostHog — product analytics. It records which pages were opened, which buttons were pressed and which requests failed, on our own screens and on creators’ pages, so we can see what is broken and what is slow. It receives an IP address and the page being viewed. It does not receive the contents of a conversation, and there is no session recording.
• Meta — measures our own advertising. It receives hashed contact details for people who sign up with us, and nothing at all about visitors to a creator’s page. See section 6.
• Cherry Servers — hosts the application and database.

We will also disclose data where the law compels us to, or to protect somebody’s safety. If in.bio is ever sold or merged, data moves with it and we will tell you before it does.

Our servers are in the United States (Chicago), and the services above are US-based too. If you are in the UK or the EU, that means your data is transferred to the US — under standard contractual clauses or an equivalent safeguard.

• Conversations are deleted after 12 months.
• Analytics events are deleted after 12 months.
• Unused uploaded images are removed once nothing references them.
• Submissions and orders stay until the creator deletes them or closes the account.
• Account data is deleted within 30 days of closing an account, apart from what tax law requires us to keep and copies in backups, which age out within 90 days.

We use as few as the service can work with:

• Session and CSRF — keeps you signed in and stops forged form submissions. Strictly necessary.
• Appearance and sidebar state — remembers light or dark, and whether the sidebar is collapsed.
• Stripe sets its own cookies on pages with a card form, for fraud prevention.
• Meta (Facebook) pixel — measures our own advertising. It sets _fbp, and _fbc if you arrived from an ad.
• PostHog — product analytics, on every page including creators’. It sets ph_* cookies to recognise the same browser returning.

The Meta pixel runs on in.bio’s own pages only: our marketing site, the legal pages, signing up, onboarding, the dashboard, and in.bio’s own creator page at in.bio/inbio, which is where our ads point. It never runs on a creator’s page. If you are reading somebody’s page or talking to their assistant, no advertising pixel is loaded and nothing about you is sent to an advertiser — we do not measure a creator’s audience on anyone’s behalf but theirs. Product analytics does run there, and only for us: it tells us which parts of the page work, and it is not advertising and is not sold or shared.

Alongside the pixel we send Meta two events from our servers: that an account was registered, and that a trial was started. Those carry your email, phone and name hashed — turned into a fingerprint we cannot reverse, which Meta can only match against an account it already has. They also carry your IP address, browser and the two cookies above, which Meta requires unhashed. Nothing about what a creator sells, what a visitor asked, or any conversation is ever sent.

Blocking the pixel — with a content blocker or your browser’s tracking protection — changes nothing about the service. To object to the server-side events, write to us at the address below and we will exclude your account.

Wherever you are, you can ask us to show you what we hold, correct it, delete it, or send it to you in a portable form. In the UK, EU and similar regimes you can also object to processing, ask us to restrict it, and complain to your data protection authority. In California you can ask what has been collected and shared, and have it deleted — and we do not sell or share personal information as those terms are defined there.

Write to hello@in.bio. We answer within 30 days. Most of it you can do yourself: your page and its content are editable and deletable from the dashboard, and closing your account removes it all.

Traffic is encrypted in transit. Passwords are hashed with bcrypt. Sessions are encrypted. Card details never touch our servers. Access to production is limited to key-based logins on a small number of accounts.

No system is perfectly secure. We cannot guarantee that a breach will never happen. If one does that affects your data, we will tell you and the relevant authority as quickly as we can, and within any deadline the law sets.

in.bio is not for under-16s and we do not knowingly collect their data. If you believe a child has given us information, write to us and we will delete it.

We will post any update here with a new date, and email you if the change is material.

The controller is InBio, Inc., a Delaware C Corporation (file number 10284507, EIN 32-0822351).

1111B S Governors Ave STE 39177
Dover, DE 19904
United States

Questions, requests and complaints: hello@in.bio. We answer within 30 days.

On a creator’s page the creator is the controller of what their visitors send them, and we are their processor — which is why a request to delete something you submitted to a page is quickest sent to them.