Privacy policy

Version 1.15 · In force from 17 October 2026

Versión en español · Versió en català

This describes how Souldi Labs SL handles personal data in Tulius. It covers both the data we control ourselves and the data we process for a customer.

Who we are

The distinction that matters most

Our role depends on why data is being handled, not on where it came from. The same person's name can fall on either side of this line depending on the purpose it is being used for.

Running the customer's workflow — the controller is our customer

The organisation that deploys Tulius decides which calls it is used on and for what purpose. They are the controller, and we are their processor, for everything that serves that workflow: what was said on a call, the proposals generated from it, the approved text, and the record of who approved what and when. We process it on their instruction and nothing else. If you were a participant on a call and want to know why it was captured, or want to object, the organisation running the call is who to ask — their own privacy notice covers it, and we cannot answer for them.

Running our own business — the controller is us

Separately, we are the controller of the limited data we handle for our own purposes: administering and authenticating user accounts, keeping the service secure, providing support, and our own commercial and contractual contacts. We decide those purposes ourselves, so we answer for them ourselves.

An approval record is the clearest example. That Joan approved a proposal at 10:42 is part of the customer's own workflow, so it sits on the customer's side of this line even though the name reached us through a Google sign-in.

What we do as controller, and on what basis

Where we rely on a legitimate interest, you can object — see Your rights. We do not rely on consent for any of the above, so there is no consent here to withdraw.

Google user data

Signing in to Tulius is done with a Google account, and Google gives us the name and work email address on it. We do not read anybody's mail or files. The further grant below is Google's own permission to see, create, change and delete events on a customer's calendars — what Tulius actually does with that permission is described there, rather than a narrower claim about the permission itself.

Where a customer connects it, Tulius sends an approved email from the organization's connected Gmail account, or from the salesperson's own account where each person connects their own, and only after a person approves it, using the narrowest Gmail permission that can send — one that can send a message and cannot read, search or alter a mailbox. It is asked for when that feature is switched on, never before, and a person has approved the message before anything is sent.

Whose calendar. A customer connects Calendar once, for the organization, or, where we have switched it on for that customer, each of its people connects their own, each on their own consent screen, and each such connection is that person's. Tulius then uses a person's calendar only for that person's own work, including the invitations that come from their work, the times offered in their replies, the bookings made through their booking page and their own Day Plan. It never uses one person's calendar for another person's work. While each person has not connected their own, because the customer has not chosen that, the organization's one calendar is used for all of it. Below, the person's calendar is the calendar used for the work in question in this way.

Where a customer connects Calendar, the permission we ask for lets Tulius see, create, change and delete events on the Google calendars of whoever connects it — Google's own words for it, and wider than what Tulius actually does. What Tulius does: for an invitation it creates one calendar event, asks Google Calendar to attach a Google Meet link to it (if Google will not, the event is created without one), and invites the guest, only after a named person has approved it on screen; it reads back that one event, to know whether the invitation was created; and when Google Calendar is connected, Tulius checks it can reach it by reading the identifier of at most one event, and keeps nothing else from that read. It never reads, keeps or shows the titles or descriptions of any of a customer's existing events, and the one place it reads who an event's guests are is described next. It is asked for separately from the Gmail permission above, on its own consent screen, so disconnecting one never touches the other. It is asked for only when somebody chooses to connect Calendar, and a person has approved each invitation before its event is created.

With the same permission, when a prospect has been offered times in a reply, Tulius looks on the person's primary calendar for a time the prospect booked through that person's booking page. It asks Google Calendar only for the events that mention the prospect's email address, and for each one takes only its start time, its identifier and the email addresses of its guests (never its title, description, location or organiser). It reads the guest list only to confirm that this prospect is on it, ignores any event Tulius itself created, and keeps nothing but the booking's start time, the prospect's address and the event's identifier, so that a person can confirm on screen which offered time was taken.

With the same permission, where a customer has switched on the Day Plan, Tulius also writes the day's Blocks that a person has approved: calendar events that hold the time for calling, each carrying only a title, a start and an end, a marker that it is Tulius's, and a link back to the Day Plan, and never a guest, a Contact's name or an email. Tulius reads each Block back by its own id, to know it is still there, and deletes the Block of a Fixed Call when the person it was for is erased (a Block that holds calls with several people goes when the last of them is erased). A Block is written to the calendar of the person whose Day Plan it is, and deleted through that calendar's own connection: if that calendar is no longer connected, the deletion waits until it is connected again, and meanwhile the event is listed in Tulius by its identifier, its time and whose calendar it is on, and nothing about the person it was for. It never changes an event it did not create. A person approves the whole plan before any Block is written, and writing Blocks stays off until the operator switches it on.

Erasing a person does not delete the event of an invitation they were sent: it is a meeting they were invited to, and deleting it would cancel it and email them. Tulius keeps that event's identifier, its time and whose calendar it is on, and nothing about the person, so that the customer can see it is still there and remove it.

Where a customer connects Calendar, Tulius also asks for the permission to see when the person who connects it is available on their calendars — Google's own words for it are "View your availability in your calendars". What Tulius does: it reads when the person is busy or free, to propose meeting times in a reply, and keeps nothing else from that read; the Day Plan reads it the same way, to plan around the person's meetings. It never reads, keeps or shows the titles, guests or descriptions of any of a customer's existing events, whether it is proposing a time or not. It is requested on the same consent screen as the permission above, because both are Calendar's, and it is granted or revoked with it.

Tulius's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not transfer this data, use it for advertising, or allow anybody to read it, except as those requirements permit.

What we process on a customer's instruction

The text of a call, the names and email addresses of the people on it, and the proposals and approvals that follow from it.

Tulius does not retain call audio. Audio is processed transiently during the call to create the transcript. Tulius captures a call itself in one of two ways, and a customer chooses which: a meeting recorder that joins the call, or, in the browser of the salesperson who starts it, with no recorder joining (see Capturing a call without a recorder joining it). Either way the audio is transcribed as it happens and discarded. Only the text is stored, and no recording of anyone's voice is kept in a customer deployment. This is about Tulius's own systems: what Recall and Deepgram keep is set out in the table under Who else is involved below.

Tulius records what was said, not how someone felt saying it. It does not use voice characteristics to profile anyone or to infer emotions or moods, and it does not run sentiment analysis on the conversation's text. This applies to customers, prospects and your own team.

Tulius registra lo que se dijo, no cómo se sintió una persona al decirlo. No utiliza características de la voz para perfilar a nadie ni para inferir emociones o estados de ánimo, y tampoco realiza análisis de sentimiento sobre el texto de la conversación. Esto se aplica a clientes, prospectos y a tu propio equipo.

Capturing a call without a recorder joining it

A customer may choose, for its whole organisation, that Tulius captures a Google Meet call from the salesperson's own browser instead of a recorder joining the call. This is off unless the customer chooses it, and it is not for any call where a recorder joins. It works like this:

• The salesperson starts it, for one meeting. The browser extension captures the audio of the meeting's browser tab and the salesperson's microphone only when the salesperson starts transcription for a selected meeting. It does not start automatically or stay active outside that meeting. Nothing is captured before the salesperson has said the notice below aloud and confirmed that they did.
• A notice is given aloud, and in the invitation. Before anything is captured the salesperson tells everyone on the call, in the customer's own wording, in the language it chose, that Tulius, an AI assistant, is transcribing the call for record-keeping and follow-up, and that anyone who would rather not be transcribed can say so and transcription will not start. The meeting invitation carries a short notice and a link to this page, with how to object, as a second layer. Neither alone is enough: unless the salesperson confirms that the invitation carries it, capture does not start, and Tulius records who confirmed and when. Tulius also records that the spoken notice was given, by whom and when. This is a notice, not a request for permission: the basis is the customer's legitimate interest.
• A participant who joins later pauses it. When someone joins after capture has started, capture pauses automatically, nothing is captured, and the salesperson is asked to give them the short notice, which says that transcription is paused while it is given and will not resume if the person would rather not be transcribed, and to confirm it was given before capture resumes. The Transcript marks the gap, and what the new participant said before the notice is not kept.
• It stops when asked, and nothing is kept if someone says no. The salesperson has a visible indicator while capture runs and a Stop button. If anyone objects, the salesperson can stop and discard: Tulius keeps no audio or transcript of that call, and a record that capture started and stopped remains.
• The route. The audio goes from the salesperson's browser to Tulius, and from Tulius to Deepgram's EU endpoint, which turns it into text. It is held in memory only while it is being processed, and is never written to disk, logged or stored by Tulius. The microphone permission Chrome shows is a technical permission and is not the legal basis.
• What the extension reads on the Meet page. Only which participants are present, by the page's own anonymous identifier for each, so that it can notice a late joiner. Not names, not the chat, not the meeting title.
• It is never used to monitor or assess the salesperson. A transcript is the record of a conversation with a customer. Tulius offers no screen, report or export that ranks, scores or compares salespeople on it. A salesperson may see statistics of their own calls, which are private to them.

The transcript that results follows the same retention, erasure and objection rules as any other (see How long it is kept and Erasing a person Tulius was used to write to). To object, or to ask about a call, write to the address under Who we are.

How long it is kept

A transcript is kept for 12 months after its call, unless a person holds it, and then the words are discarded. The record of what people decided about the call — the proposals and the approvals — outlives the transcript, because that record is what the customer uses the product for. Once the words are gone, nothing new can be grounded in that call.

Deletion on request is separate and immediate in our own systems: a customer can have a call and everything derived from it removed at any time, without waiting for a retention period to come due. What we cannot delete on your behalf is anything a provider holds under its own retention rules, or a copy that has already been written into the customer's own CRM or mailbox at their instruction — those are reached through that provider or that customer, and we will say which applies to any given request.

Deleting the words does not make everything else anonymous. A follow-up email, a CRM note or an approval record can still name people and describe what they said. Those are kept for as long as the customer keeps them, because they are the customer's business records rather than ours to expire.

Erasing a person Tulius was used to write to

Tulius drafts first emails to people a customer chose from their own CRM — people who never asked to hear from us or from the customer. On the customer's request, everything Tulius holds under one person's CRM record is erased in one step, and immediately in our own systems: the emails drafted to them, the operator's own notes of any calls made to them, the record of which openings and messages they have already had, the drafts queued for them, and the record that they asked not to be called (who recorded it and when, and any lift of it). It is done by the CRM record and never by email address alone, because two records can share an address and erasing by address would erase somebody who never asked. Where Tulius holds records for the same address under other CRM records, the erasure says how many, so the request can be made again for each; it does not erase them.

Two things are kept, on purpose, so that erasing does not undo itself. The first is the do-not-contact flag, which lives on the person's record in the customer's HubSpot rather than with us, and which we never touch — it is what stops the next email to somebody who asked us to stop. The second is a small record that the person was erased: their HubSpot record id, the date, who asked, and how many records of each kind went, and nothing that was in them — not a name, an address or a word of a message. Without it, deleting the emails we had written would make the person look like somebody we had never written to, and Tulius would be free to write to them again. That id is itself personal data, kept so that Tulius stays unable to write to them. Nothing in the product removes it; asking for it to go as well is asking to be written to again, and that is a decision for the customer as the controller.

What this does not reach. Anything from a call the person was on: a call is removed as a whole, at the customer's request, and until it is the person can appear in its text and in what was proposed from it. And what Tulius proposed about a company from that company's own public website: those proposals are kept against the company and not the person, are not found or erased by a name, and can quote a sentence the company itself published that names somebody. Removing them is a separate request, made for one company at a time: deleting a company's proposals deletes them, and the record of having asked for them, at once in our own systems, and touches nothing in the customer's HubSpot. A small record that it happened is kept — who asked, when, and how many, and nothing that was in them — and it is also what stops Tulius reading that company's website again by itself: only somebody asking for it does. Deleting the records of asking for a company's proposals does not delete what asking cost, because Tulius counts what it has spent on reading websites: for each such record a small line is kept — the date, that one model call was made, and which model and how many tokens it reported, and nothing that was read. It names no company and no person, is kept without a time limit, and cannot be traced to a company except through the record of the deletion above. And they are not kept for ever: a proposal a person has decided (declined, or approved and written to the customer's HubSpot) is deleted six months after that decision, and one that a newer proposal for the same company has replaced is deleted six months after the newer one arrived. A proposal still waiting for a decision is not deleted by the passing of time. The copy already in the customer's HubSpot — the note, the lead status — and the email itself in the customer's Gmail, which are the customer's own systems. And any file the customer's operator wrote to their own computer while running the outbound workflow. And anything a provider holds under its own retention rules, as described above. Those are reached through the customer or the provider, and we will say which applies to any request.

How we choose what a message is about

Who is responsible

The organization contacting you decides whether to use Tulius to personalize commercial messages and is the controller of your personal data for that purpose. Tulius processes the information on that organization's instructions.

How personalization works

When an organization enables message personalization, Tulius may use your job title, public information about your company, relevant things you have said in business communications, and notes written by the organization to generate a Hypothesis about your possible professional responsibilities or business needs.

A Hypothesis is an unverified inference, not an established fact. It helps the organization choose a potentially relevant topic for a message. This constitutes profiling for direct marketing under Article 4(4) GDPR. It is not used to make decisions that have legal or similarly significant effects on you.

What information is kept

Tulius distinguishes between statements you made, notes written by others, and AI-generated Hypotheses. Where available, it records the source and date of the supporting information.

A Hypothesis is stored with the message for which it was generated and is accessible to authorized staff of the organization. It is deleted according to the applicable message-retention period and when your personal record is erased, subject to any applicable legal retention requirements.

You may request access to personal data about you, including relevant Hypotheses and underlying records, and request correction of inaccurate information.

Business communications and notes

Separately from message personalization, the organization may retain relevant information from business calls, emails and notes for customer-relationship management and follow-up, under its applicable privacy notice and retention rules.

Disabling message personalization prevents that information from being used to generate marketing Hypotheses. A note written by someone else is not treated as a statement you personally made.

Previews

Before personalization is enabled, demonstrations use fictional contact information. Any preview involving real contacts requires separate activation by the organization and is subject to the same data-protection requirements as other marketing profiling, even when the resulting messages are not sent.

Your right to object

You may object at any time, free of charge and without giving a reason, to the use of your personal data for direct marketing, including related profiling.

You can reply "no" to a commercial email or contact the organization directly. You can also contact Tulius using the address provided in this privacy notice, and we will forward your request to the responsible organization.

Following an objection to direct marketing, your personal data will no longer be used for that purpose, including related profiling. A minimal suppression record may be retained to ensure that your objection is respected.

How messages are written

Where a proposed message relies on an unverified Hypothesis rather than something you have said, Tulius is designed to express it as a question, not as an established fact about you.

Sensitive information

Tulius is designed not to use sensitive personal information or criminal-offence data to personalize commercial messages. This includes information revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, health, genetic or biometric identification data, sex life, sexual orientation or criminal matters. Such information must be excluded from personalization inputs and outputs.

What the organization tells you itself

Who the organization is and how to contact it, how long it keeps messages and business notes (the periods or the criteria), the legal basis on which it contacts you and where it obtained your details are for that organization to tell you, in its own privacy notice. Tulius does not decide or state them, and this page does not fill them in.

Learning how a person writes from emails they paste, if the organization switches this on

If the organization that uses Tulius has switched it on (it is off by default, and it is the organization, not a salesperson, that switches it on), a person can paste some of their own sent emails so that Tulius learns how they write. It extracts rules for prompts and fine-tunes no model. A rule is about how a message is written (a greeting, how formal it is, how long the sentences are, how a message is built and closed), never about what a message says, and each rule is offered to the person, who decides whether it is ever used. The model only classifies the habits of the emails; the wording of each rule is a fixed text written by Tulius, not text the model generates. This is a limited pilot for the organization that runs this deployment of Tulius, and it has not been assessed for any wider use.

The emails are redacted in the person's own browser before anything is sent: the common names and identifiers it recognises (email addresses, phone numbers, signatures, links) and quoted earlier messages become placeholders, a name it does not recognise can remain, and the person sees the result first and can remove anything. Tulius refuses a batch that holds attachments, health, religious, political or union information, criminal-offence data, children's data, private or family correspondence, messages to personal addresses, legal advice, security incidents, credentials or confidential deal details, and the person confirms the batch holds none of these. Tulius does not retain the submitted email text in its application storage. It is held in memory only while the rules are proposed, is deleted when the proposals are made, and is not kept if the reading fails. The analysis is confined to the author's own writing. Cancelling withdraws what the reading offered, but a reading already sent to the model is not recalled. The redacted text is sent to the provider of the model to propose the rules; what the provider keeps is stated separately below. What is kept is a random batch id, the times, counts, whether a rule was approved, and that the text was deleted, never a subject, a recipient or a body. A rule learned this way can be erased, with its record, when the organization asks for the person concerned.

What the model provider keeps is a separate matter from what Tulius stores. Anthropic deletes API inputs and outputs within 30 days. If Anthropic's automated safety systems flag a request as violating its usage policy, it keeps the inputs and outputs for up to 2 years and the classification scores for up to 7 years. Tulius has no zero-data-retention agreement with Anthropic, so the terms of Anthropic's commercial offering, which covers API use, apply (Anthropic's retention, zero data retention).

LinkedIn messages, if a person switches this on

The Tulius browser extension can read a person's LinkedIn messages with people who are already contacts in the customer's HubSpot, and the date a contact accepted a LinkedIn connection. It is off by default. A person switches it on for themselves, after a screen that explains what is read and says that LinkedIn's terms do not authorise it, and the confirmation is recorded with who gave it and when. It can be switched off at any time, which stops it at once and deletes nothing already logged.

Switching it on may expose the person's LinkedIn account and the Tulius service to restrictions or other enforcement by LinkedIn.

Los términos de LinkedIn no lo autorizan, y activarlo puede exponer la cuenta de LinkedIn de la persona y el servicio de Tulius a restricciones u otras medidas por parte de LinkedIn.

What is read. Only in the person's own browser, on LinkedIn's messaging and connections pages, and only for a person who is already a contact in the customer's HubSpot, matched by their LinkedIn profile address and never by name. For each message: who sent it (the person or the contact), when, and the text, which stay in the person's browser until the person has seen them and chosen to keep them. For each LinkedIn connection: the date. A conversation with anybody who is not a HubSpot contact is never read: it does not leave the browser. Nor is a conversation with more than one other person (a group) read at all. The extension does not click, scroll, open pages or send anything on LinkedIn, and no server of ours fetches a LinkedIn page or holds a LinkedIn password or session.

Nothing is logged until the person has seen it. Matched messages are held in the person's browser, shown as "N new messages with <name> ready to log", and the person excludes a whole conversation or single messages and confirms before anything leaves the browser. A message the person excludes is never sent to Tulius, and Tulius keeps no record of its text or of how many were excluded. When a contact has written, the extension tells Tulius that a reply arrived, without what it said, so that nobody who has replied is sent another message.

If a message that should not have been logged was logged, the person removes it from the CRM from the extension. Tulius deletes it and keeps a record that it did so (who, when, and HubSpot's identifier for the message, never what it said) for 24 months, or until the contact is erased.

When a page cannot be read. If the extension cannot read a LinkedIn page, it tells the web app which kind of page it was and which version of its reader tried, so that a broken reader is noticed. That report is recorded with the person who sent it and kept for 30 days. It carries no message, no name of anyone on LinkedIn and no LinkedIn address.

Legal basis. The customer is the controller. Its basis is its legitimate interest in business-to-business prospecting, the same basis as for the text of a call, and you have the right to object (see Your rights).

Where it goes and for how long. The messages are logged in the customer's HubSpot, on the contact, and the LinkedIn connection date is written to the contact's record. Tulius keeps no copy of its own. They are kept for as long as the contact is kept in HubSpot, the same as that contact's emails, or until erased on request.

Erasure. When a person is erased in Tulius, by their HubSpot record, Tulius also deletes the LinkedIn messages it logged on that contact in HubSpot. This is said for these messages specifically; for any other copy in the customer's HubSpot, what is said under Erasing a person Tulius was used to write to still applies. The record Tulius keeps of a message that was removed from the CRM is deleted with the contact.

What erasure cannot always reach. Tulius deletes the messages it logged and recorded HubSpot's identifier for. If HubSpot did not confirm that it filed a message (it timed out, or did not answer), Tulius has no identifier for it and does not search HubSpot for it, so that message may remain in the customer's HubSpot. Tulius shows the customer each such logging so that a person can look for it in HubSpot and remove it, and the record of the erasure counts them rather than claiming they were deleted. Erasure does not clear the LinkedIn connection date on the contact's record, which stays the customer's.

Where it is processed

The application and the database run in Frankfurt, in the EU. Each customer has a deployment of their own with its own database, so one customer's calls are never held alongside another's. That is where a transcript is stored and where it stays.

Reading a transcript is done by a model Anthropic operates, and that step is not confined to the EU. To generate a proposal, the text of a call is sent to Anthropic's API. Anthropic may route that request to servers in the United States, Europe, Asia or Australia, and its own account data is held in the United States. We say this plainly rather than describing Tulius as an EU-only service, because the sentence a reader needs is the one about the whole chain and not the part of it we host.

Sending data outside the EEA

Where a provider processes data outside the European Economic Area, that transfer is covered by the European Commission's Standard Contractual Clauses, incorporated in our agreement with that provider. You can ask us for information about the safeguards that apply by writing to joan@souldi.io.

How it is protected

What protects the data described above, and what each mechanism actually does — not more.

The database has no public address, by default. Every external connection is blocked, and the application reaches it over our hosting provider's private network rather than a shared one. That block can be lifted, deliberately and briefly, for us to rehearse restoring a backup — an act somebody decides to perform and undoes afterwards, not a door left open.

Our hosting provider, Render, encrypts the database at rest using AES-256. That protects a copy of the database — a backup, a disk that is decommissioned without being wiped — rather than a process that already holds the data while it is running.

A connected account's tokens are sealed again, independently of the database. Where a customer connects Tulius to their own HubSpot, the access and refresh tokens we hold for that connection are encrypted before they are written to a row, with a key our deployment holds and the database itself does not. What that buys, said exactly: a copy of the database on its own cannot be used to write into a customer's account. It does not protect against somebody who already has the running application, and it is not a substitute for the database having no public address, which is the paragraph above.

The application is reached only over TLS. A plain HTTP request to app.tulius.app is redirected to HTTPS rather than answered.

Access to the hosting workspace that can reach production data is limited to named individuals and requires two-factor authentication. It does not protect against someone who holds that access.

Who else is involved

These act on our instruction, as our processors, to deliver the service.

Two others are involved but are not the same thing. They are systems the customer already has and chooses to connect, under their own agreement with that provider rather than ours:

Your rights

You can ask for access to your data, its correction, its erasure or the restriction of its processing; you can ask for a copy in a portable form; and you can object to processing that rests on a legitimate interest.

Which door depends on who the controller is. For anything said on a call, or any record produced from one, the organisation that ran the call is the controller and is the right place to ask — we will pass on any request that reaches us, act on that organisation's instructions, and tell you where it went. For the things we control ourselves, listed above, write to us directly at joan@souldi.io.

You can also complain to a supervisory authority. In Spain that is the Agencia Española de Protección de Datos.

You also have the right to complain to a supervisory authority in the country where you live or work.

The browser extension

Tulius offers an optional Chrome extension. In Chrome's side panel, it shows a user read-only information from their organisation's Tulius deployment: today's Briefs and new Execution Packages and Reminders that require that user's attention after a call. The extension cannot approve, reject, edit or execute anything. Any action that changes data opens the Tulius web app, where a person decides. There are two exceptions. The first is LinkedIn capture, which is off unless a person switches it on: it logs, once the person has confirmed them, that person's LinkedIn messages with HubSpot contacts in HubSpot (see LinkedIn messages).

Who controls the data. The organisation using Tulius is the controller of the Deal, contact, call, Brief, Execution Package and Reminder data shown through the extension. Souldi processes that data as the organisation's processor and on its instructions. Souldi remains the controller of the limited account, authentication, security and support data described earlier in this policy.

What it reads. The extension reads only the information returned by the user's organisation's Tulius deployment: today's Briefs and the Execution Packages and Reminders that require attention after a call. These can include Deal names, people's names and what was agreed during calls. The one exception is LinkedIn's messaging and connections pages, if a person switches that on: see LinkedIn messages. The second is a Google Meet call, when the customer has chosen to capture without a recorder and the salesperson starts it: the extension then reads which participants are present (an anonymous identifier for each, never a name, the chat or the title) and captures the tab's audio and the salesperson's microphone, as described under Capturing a call without a recorder joining it.

If the user chooses to add a HubSpot address, the extension can also see the full web address of the current tab when it is on either of the two sites the user has authorised. It examines that address locally and uses it only to recognise a HubSpot Deal page by its Deal identifier and place the corresponding Brief first. On a HubSpot page it reads that address and nothing else. It does not read the contents of the page, match a Deal by its name or send the tab's web address anywhere. The only pages whose contents it reads are LinkedIn's messaging and connections pages, and only if a person allows that (see LinkedIn messages).

What it stores and for how long. The extension persistently stores only the following information in Chrome's local extension storage on that computer (seven items):

• the address of the user's Tulius deployment;
• the HubSpot address, if the user chooses to add one; and
• an identifier for the newest Execution Package the user has viewed, used to determine which items are new; and
• if a person has allowed LinkedIn capture, the counts of its last run: when it ran, how many conversations or connections were matched to a HubSpot contact, how many messages were held and how many dates were logged, how many could not be logged, and how many pages could not be read;
• if a person has allowed LinkedIn capture, a list of the messages it logged in the last 30 days, kept only so a person can remove one (who sent each, when, the other person's name as LinkedIn shows it, and an identifier from Tulius; no message text);
• if a person has allowed LinkedIn capture, a short one-way code for each message the person has logged or excluded, so it is not offered again (no text); and
• if a person has allowed LinkedIn capture, a short one-way code for each message from a contact whose reply Tulius has still to be told of (no text).

A browser capture's state (anonymous codes of the participants, the words the salesperson was shown, and whether it is running) is kept only in the browser's memory, never on disk, and no audio is kept on the computer.

Held messages are kept only in the browser's memory, never on disk, and are dropped when the browser closes or after 24 hours. The list of codes of messages logged or excluded, and the list of replies still to be told to Tulius, are cleared when capture is switched off, by the person or by Tulius, and the first also when the person clears it. The list of messages logged in the last 30 days is kept when capture is switched off, because removing a message must still work then, and an entry leaves it after 30 days.

Briefs, Execution Packages, Reminders and tab addresses are not written to Chrome's local extension storage. Stored addresses remain until the user changes them or removes the extension. The newest-item identifier is replaced as the user views newer items, and the counts are replaced by the next run. Chrome clears all of this local extension storage when the extension is removed.

What it sends and to whom. The extension connects only to the user's organisation's Tulius deployment, which Souldi hosts and operates as the organisation's processor. That deployment is hosted by Render, as described under Who else is involved. The extension does not send data to Google, HubSpot, analytics services, advertising services or any other new recipient.

Once the extension has been configured and the user has accepted its disclosure, it sends requests to the Tulius deployment when the side panel opens, when Chrome starts, after the extension is installed and configured or its address is changed, and approximately every 15 minutes while Chrome is running so that the toolbar can show the number of new items. If a HubSpot address has been added, it also refreshes the information as the user moves between authorised tabs. These requests only read, with one exception: LinkedIn capture, if a person allows it. On each LinkedIn messaging or connections page it asks the same deployment whether capture is on, and then the LinkedIn profile addresses of the people shown (in a conversation, or on your connections page) are sent to Tulius only to check which are already HubSpot contacts; for anyone who is not, nothing else is sent and nothing is kept. For a HubSpot contact it sends the connection date, to be logged, and a note that a reply arrived; it sends the messages only after the person has seen them and chosen to keep them (see LinkedIn messages). Neither the tab address nor the information held in Chrome's local extension storage is included in those requests.

As with a request made through the Tulius web app, a request from the extension necessarily provides the deployment with the connection and authentication information needed to return the authorised data, including the IP address, request time and ordinary browser and network headers. This information may appear in access and security logs and is kept for no longer than 30 days. Those logs do not contain the tab address or the contents of the Briefs, Execution Packages or Reminders returned to the extension.

Disclosure and permissions. Before the extension reads Tulius information or a tab address, it displays this disclosure in its own panel and requires the user to agree. Only then does it ask Chrome for access to the Tulius and optional HubSpot addresses entered by the user. Apart from LinkedIn, if a person switches that on (see LinkedIn messages), and Google Meet, when the salesperson chooses to allow it for capture without a recorder, it does not ask for access to any other site. For that capture it also uses two Chrome permissions, to capture a tab's audio and to hold the audio in the extension while the call lasts, and it asks for access to Google Meet only when the person chooses to allow it. Access to the two LinkedIn pages is asked for only when the person chooses to allow it, never when the extension is installed, and only then does the extension use Chrome's permission to register its LinkedIn script, which it does for those two pages and no others.

The use of information received from Google APIs by the Tulius browser extension will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.

Cookies

This site sets no cookies, loads nothing from another domain, and runs no analytics. The application at app.tulius.app sets one cookie, which keeps you signed in and does nothing else.

Changes

This page carries a version and an effective date. If it changes materially we will tell customers rather than relying on you noticing.

Version 1.15, 17 October 2026: says that an approved email is sent from the organization's connected Gmail account, or from the salesperson's own account where each person connects their own, and only after a person approves it, where it said the email was sent as the person who approved it; that, where we have switched it on for a customer, each of its people may connect their own Google Calendar, that each such connection is that person's, and that Tulius uses a person's calendar only for that person's own work and never for another person's, with the organization's one calendar used for all of it while each person has not connected their own; that the Calendar paragraphs speak of the calendar, booking page and availability of the person whose work it is, where they said the operator's; that the free/busy read also lets the Day Plan be planned around a person's meetings; that a Day Plan's Blocks are written to the calendar of the person whose Day Plan it is and deleted through that calendar's own connection, waiting, listed in Tulius by its identifier, its time and whose calendar it is on, where that calendar is no longer connected, and that a Block holding calls with several people is deleted when the last of them is erased; and that erasing a person does not delete the event of an invitation they were sent, of which Tulius keeps the identifier, the time and whose calendar it is on, and nothing about the person. What Tulius reads, writes and keeps with the Calendar permissions is otherwise unchanged, and writing Blocks stays off until the operator switches it on. The Spanish and Catalan versions gain a section on Google Calendar and Gmail with the same paragraphs.

Version 1.14, 9 October 2026: adds How we choose what a message is about, in the text approved by counsel on 9 October 2026: that the organization contacting a person is the controller of the personalization and Tulius processes on its instructions; what a Hypothesis is (an unverified inference, profiling for direct marketing, never a decision with legal or similarly significant effects); what is kept, from where and for how long, and that an access request reaches it; what happens to business communications and notes when personalization is off; that previews before personalization is enabled use fictional contacts; the right to object and how; that a message resting on a Hypothesis asks and does not state; and that nothing sensitive is used; with a closing paragraph, ours, saying what the organization tells the person itself. Adds a Spanish version (Versión en español) and a Catalan version (Versió en català) of the personalization section and of the information about browser transcription. Tailoring stays off by default and this change switches it on for nobody.

Version 1.13, 9 October 2026: says that Tulius does not retain call audio and that audio is processed transiently during the call to create the transcript; that Tulius captures a call in one of two ways, through a meeting recorder that joins or, if the customer chooses it, from the salesperson's own browser with no recorder; how browser capture works (the salesperson starts it for one meeting, the notice given aloud and in the invitation, capture pausing for a late joiner, Stop and discard, and nothing kept if someone objects); that it is never used to monitor or assess the salesperson; that Deepgram receives the audio either through Recall or directly through Tulius; and what the extension reads on a Meet page and which permissions it uses for it. Browser capture stays off by default and this change switches it on for nobody. It also states the period a transcript is kept (12 months after its call, unless a person holds it), where the page said only that it was agreed with the customer. These paragraphs are written in English only.

Version 1.12, 7 October 2026: says that LinkedIn messages are held in the person's browser until the person has seen them and chosen to keep them, that a message the person excludes is never sent to Tulius and no record of its text or of how many were excluded is kept, that the extension tells Tulius a reply arrived without what it said, that a person can remove a logged message from the CRM from the extension and Tulius keeps a record of the removal (who, when and HubSpot's identifier for the message, never its text) for 24 months, and that the extension stores three more lists of no message text and when each is cleared, that the record of a removal is deleted with the contact on erasure, and that the extension's overview says capture logs only messages the person has confirmed. LinkedIn capture stays off by default and this change switches it on for nobody. These paragraphs are written in English only.

Version 1.11, 6 October 2026: says what Tulius does with the Calendar permission beyond creating an invitation's event: it looks on the operator's own primary calendar for a time a prospect booked through the operator's booking page, asking only for events that mention the prospect's address and taking only an event's start time, identifier and guests' addresses, to confirm the prospect is a guest, and keeping only the booking's start, the prospect's address and the event's identifier; and, once day planning is switched on, it writes the day's Blocks a person has approved (a title, a start and an end, a marker that it is Tulius's and a link to the Day Plan, never a guest, a Contact's name or an email), reads each back by its own id, deletes the Block of a Fixed Call when the person it was for is erased, never changes an event it did not create, and that writing Blocks stays off until the operator switches it on. The sentence that Tulius never reads the guests of an existing event is replaced, because the booking read does read an event's guest addresses. These paragraphs are written in English only.

Version 1.10, 2 October 2026: says that the LinkedIn screen tells a person that LinkedIn's terms do not authorise capture and that switching it on may expose their LinkedIn account and the Tulius service to restrictions or other enforcement, in English and Spanish. LinkedIn capture stays off by default and this change switches it on for nobody.

Version 1.9, 2 October 2026: states that Tulius records what was said and not how anyone felt saying it, with no voice-based profiling, no inference of emotions or moods and no sentiment analysis of text; and says that a report that a LinkedIn page could not be read is recorded with the person who sent it and kept 30 days.

Version 1.8, 2 October 2026: the browser extension section now describes LinkedIn capture as built: the extension stores a fourth item (the counts of its last run, never a name or message), the requests it makes when a person allows LinkedIn capture, how and when it asks for access to the two LinkedIn pages, that group conversations are never read, and that a message whose filing was not confirmed may remain in HubSpot after an erasure.

Version 1.7, 1 October 2026: adds LinkedIn messages, if a person switches this on: what the extension reads on LinkedIn, that a person who is not a HubSpot contact is never read, the legal basis, how long the messages are kept, and that erasing a person also deletes them.

Version 1.6, 26 September 2026: narrows the second Calendar permission Tulius asks for, from seeing events on all of the operator's calendars to seeing when the operator is available, and removes the mention of reading the identifier of the operator's primary calendar, which Tulius no longer does. What Tulius does with Calendar is otherwise unchanged.

Version 1.5, 26 September 2026: adds Recall.ai and Deepgram to Who else is involved, describes how Recall's copy of a call's media is deleted and how that is confirmed, states that Tulius does not retain audio in its own systems, and corrects the description of what Tulius does with Google Calendar.