Privacy Policy

TimeScout is run by MasterKey LLC, 9051 Mira Mesa Blvd #261229, San Diego, CA 92126, United States.

We are the data controller for your account: your name, your email address, what you bought and what you clicked. We are a processor for the message content you connect, which stays yours and is analysed only to produce your results.

We have not appointed an EU or UK representative under GDPR Article 27 yet. Requests from the EU, the EEA and the UK go to customersupport@timescout.ai and are answered within 30 days, the same as every other request.

TimeScout reads the communication you connect and works out which parts of your week are busywork an agent could take over. A scan runs a fixed pipeline: it ingests your messages, classifies each one as personal or noise, clusters the personal ones into recurring patterns, discovers the roles (“hats”) you wear, extracts the promises you made, and composes agent opportunities from what it found. Everything it produces — clusters, roles, opportunities — is derived from your own messages.

We are the data controller for your account, and a processor for the message content you connect. Your correspondents are not our customers and cannot answer for themselves, which is why the pre-scan disclosure exists and why we keep the analysis to the minimum the product needs.

• Email: Gmail, Outlook, iCloud Mail, Yahoo Mail, Fastmail, Zoho Mail — If you connect it: senders, recipients, subjects and body text for the window you pick. Gmail: everything in that window, Trash included, never Spam. Outlook connected by you: your Inbox, Sent and Archive folders only, never Deleted Items, never Drafts, and never a custom folder. Outlook included through your company's Microsoft 365: every folder of the mailbox — Deleted Items, Archive and every custom folder included — except Drafts, Outbox and Junk Email, which are never read. iCloud Mail: the mailbox your app-specific password opens. Yahoo Mail: the mailbox your app password opens. Fastmail and Zoho Mail: the mailbox your app password opens. Any other IMAP mailbox: the one your app password opens on the host you typed. TimeScout has no send, draft, delete or modify path for any mailbox.
• Slack — If you connect it: your DMs and the channels you take part in. A big channel you never post in is read too, then marked as noise rather than your work, which by default keeps only its headers and counts.
• Calendar: Google and Outlook — If you connect it: event titles, times and attendees. Read-only.
• Meeting transcripts: Zoom, Fireflies (plus Otter / Read AI notification emails) — If you connect it: meeting titles, participants and transcript text for the window you pick. Read-only — we never join, record, send or delete anything. Otter and Read AI transcripts arrive through their notification emails in a connected inbox.
• CRM: HighLevel — If you connect it: your location's conversations (SMS, email, calls and their transcripts, social messages), appointments, pipeline opportunities, the contacts they touch (their tasks and notes), your team's names and emails, and your automation inventory (workflow, funnel, campaign and calendar names). Read-only — we never send, edit or delete anything in your CRM.
• Payments: Stripe — If you connect it: your payments and which failed, invoices and how often each has been chased, subscriptions and cancellations, refunds and disputes with their reasons and dates, and payouts. We never open your customer list. Stripe puts identity on the payments themselves — a billing name, email, phone or address on a payment, the customer details on an invoice, the evidence on a dispute, the card's last four, expiry and fingerprint — and all of it is dropped before anything is stored. Two things about the instrument itself stay, because neither names anybody: how it was paid (card, bank transfer) and the card's brand, such as Visa or Mastercard. What you yourself put in a payment's metadata is kept as you wrote it. We write a note to work through only for the things somebody has to handle — a dispute, a refund, a failed payment, an invoice being chased, a failed payout. A payment that simply went through is not one of them. Read-only.
• Attribution: Hyros — If you connect it: your leads and where each one came from (the traffic source, the campaign and the ad), your sales with their amount, currency, product and whether they were refunded, and your booked calls with how each went. The lead each sale and call belongs to is read too, so a conversion rate is counted per source rather than guessed. A lead's NAME is dropped before our own copy of the row is written; their email address and phone number are stored encrypted beside it rather than in plain text. The ad, campaign and product names, the amounts and the dates are kept as Hyros sent them. We write a note to work through only for the things somebody has to handle: a qualified lead who has not bought, a booked call that did not happen, and a sale that came back. A lead who behaved exactly as a lead should is not one of them, and that note carries the lead's email address the way every message row in TimeScout does, so the same person lines up across your inbox and your CRM. Read-only: we never create, edit or delete anything in Hyros.
• Database: Supabase — If you connect it: the shape of your app's own database. Your table names, the columns in each table with their types, how many rows each holds, when a table was last written to, and the foreign keys between tables, so we can see what relates to what. We read a small sample of rows per table and redact it before anything is stored. Your auth users, your secrets and your storage objects sit outside the schema we read, and we never open them. Read-only: the connect check refuses a role that can write.
• App code: GitHub (a Lovable, Bolt or React app synced to one repository) — If you connect it: the file list and the source files of the one repository you name, read to inventory the app's screens, the forms on them and the Supabase tables each screen reads and writes. Read-only. Nothing is pushed, no other repository is opened, and issues, pull requests, Actions runs, secrets and environment variables are never read.
• Advertising: Meta Ads — If you connect it: your ad accounts with their currency, time zone and whether an account is disabled and why, and your campaigns, ad sets and ads with their names, budgets, bid strategy and status. That includes the things somebody has to fix: a disapproved ad and the policy behind it, an ad set stuck in learning, an account that stopped delivering. We never read Lead Ads form submissions, which are the names, emails and phone numbers people typed into your ads. We never open an ad's creative, so its headline, body copy and images are not read and not stored. We never read your audiences: a custom audience's name usually describes the people in it, so the targeting on an ad set is dropped before anything is stored. We never read the card or bank account behind an ad account. Read-only; nothing is created, paused, edited or deleted.
• Microsoft Teams — If you connect it: your one-to-one, group and meeting chats, which are the only ones the API returns to us. We do not read Teams channels. Sender and @mention identities are resolved from your directory so the same person matches across your other sources. Read-only.
• Asana — If you connect it: the tasks assigned to you and the comment threads on them. A task you merely follow is not read. Read-only.
• Process documents: Notion, Confluence — If you connect it: pages whose titles look like a process or an SOP. We store the title, the body and any owner named on it as your process inventory. Only the titles are sent to the model. Read-only.
• Automation definitions: Make, n8n, HubSpot workflows, Process Street, Zapier export — If you connect it, or upload your Zapier export: the names of your workflows, their steps and the expressions inside them, stored as the platform returns them. A credential the platform holds is recorded as an app name only. A value somebody typed into a step by hand is part of that step, so it is stored with it: keep secrets in your platform's credential store rather than typed into a field. Read-only.
• Desktop screen activity: the Screenpipe bridge — Only if you install it: the bridge runs on your own machine and sends us what you point it at. App names, window titles, samples of the text on your screen read by OCR, and excerpts of meeting transcripts. The raw text is deleted on the same window as your message bodies; the summaries and counts it produced are kept. You choose what the bridge watches, and revoking its key stops it.
• Google Workspace, connected for the whole company — If a super admin authorizes it: TimeScout reads the Gmail, Calendar and directory entry of the people that admin includes, with no separate consent screen for each person. Everyone included is emailed a notice naming the admin who did it. Any of them can stop the reading from their own account, and the admin can withdraw the whole authorization in their Google Admin console. Read-only.
• Desktop imports: iMessage, WhatsApp, Telegram — Only if you install the desktop app and pick the chats to import — nothing is uploaded that you didn't select.
• The people you talk to — Inside a source you connect, your correspondents' names, addresses and messages are read too — you're deciding that on their behalf.

What we ask each provider for is read-only wherever the provider allows it, and the table below says where it does not. TimeScout has no send, draft, delete or modify path for any connected account.

The exact permissions we ask for

These are the permission strings each provider shows you on its own consent screen. Two lines follow each one. Allows is what granting that permission would let an app do; the label says whether that is the provider's own wording or our plain-English summary of it, because a summary dressed as a quotation is its own small dishonesty. What we do is what TimeScout actually does with it, and what it never does. Where a row is not read-only, that gap is the whole point of printing both. Sources with no scope strings use a key you create, a file you upload, or the desktop app.

• Gmailread-only: no
  • https://mail.google.com/
  • https://www.googleapis.com/auth/userinfo.email
  • https://www.googleapis.com/auth/userinfo.profile

  Allows (the provider's own wording): Read, compose, send, and permanently delete all your email from Gmail. See your primary Google Account email address. See your personal info, including any personal info you've made publicly available.

  What we do: Reads the messages in your scan window, headers and bodies, Trash included and Spam never, plus the email address on your Google account so we know whose mailbox it is. The profile scope would also expose your personal info; no lane reads it. There is no code path that sends, drafts, replies, moves, labels, trashes or deletes mail.

  The wording on the left is Google's own, and that mail scope really does carry compose, send and permanent delete. A read-only mail scope is refused at the consent screen, because Google verifies restricted scopes per client and the client we connect through is not verified for one. We kept the verified bundle and published this split rather than ship our own client. If you connected Gmail before 9 September 2026 you consented to a wider bundle that also covered contacts, birthday, phone and address reads we never used; that grant stands until you disconnect and reconnect Gmail, which moves you to these three.

• Google Calendarread-only: no
  • https://www.googleapis.com/auth/calendar
  • https://www.googleapis.com/auth/calendar.events

  Allows (the provider's own wording): See, edit, share, and permanently delete all the calendars you can access using Google Calendar. View and edit events on all your calendars.

  What we do: Reads event titles, times and attendees in your scan window. There is no code path that creates, edits, shares or deletes an event or a calendar. The whole Calendar surface is a single list-events read.

  These two scopes permit writes and Google words them that way. They are the only ones Google lets us use on this client: the read-only pair is refused at the consent screen. We kept the verified bundle and published this split rather than ship our own client.

• Outlook mail and calendarread-only: yes
  • Mail.Read
  • Calendars.Read
  • MailboxSettings.Read
  • User.Read
  • offline_access

  Allows (in plain terms): Read your mail. Read your calendars. Read your mailbox settings. Sign you in and read your profile. Maintain access to data you have given it access to.

  What we do: Reads your Inbox, Sent and Archive folders and your calendar events for the scan window. Never Deleted Items, never Drafts, never a custom folder. Nothing in TimeScout reads your mailbox settings at all. That permission arrives with the bundle and sits unused. The profile read is how we know whose mailbox it is, and the last one is what keeps the connection alive between scans instead of asking you to sign in again.

• Slackread-only: yes
  • channels:history
  • channels:read
  • groups:history
  • groups:read
  • im:history
  • im:read
  • mpim:history
  • mpim:read
  • users:read
  • users:read.email

  Allows (in plain terms): View the messages and other content in the public channels, private channels, direct messages and group direct messages that TimeScout has been added to, and basic information about each of those. View the people in the workspace and their email addresses.

  What we do: Reads your direct messages and the channels you take part in, for the scan window. A big channel you never post in is still read, then marked as noise rather than your work, which by default keeps only its headers and counts. The people and email reads are how a Slack handle is matched to the same person in your other sources. Nothing is posted, edited, reacted to or deleted.

• Microsoft Teamsread-only: yes
  • User.Read
  • Chat.Read
  • ChatMessage.Read
  • ChannelMessage.Read.All
  • Team.ReadBasic.All
  • Channel.ReadBasic.All
  • offline_access

  Allows (in plain terms): Sign you in and read your profile. Read your chat messages. Read your channel messages. Read the names and descriptions of teams. Read the names and descriptions of channels. Maintain access to data you have given it access to.

  What we do: Reads the one-to-one, group and meeting chats you are in. Channel messages are not read: there is no code path that lists or reads a channel message, and the channel and team permissions are for a lane that does not exist yet. Sender identities come from your directory when your tenant lets us read it; when that read is refused, senders keep their display names and the scan says so. Nothing is posted or deleted.

  The channel permissions are pinned at the auth config rather than chosen at each connect, so we cannot drop them without replacing the config. They are named here rather than left quiet.

• Asanaread-only: yes
  • tasks:read
  • projects:read
  • stories:read
  • users:read
  • workspaces:read
  • teams:read

  Allows (in plain terms): Every one of these ends in :read, and Asana offers a write counterpart for each that we did not ask for. Together they view your tasks, the projects they sit in, the stories (the comments and activity on a task), and the users, workspaces and teams they belong to.

  What we do: Reads the tasks assigned to you and the comment threads on them. A task you merely follow is not read. Nothing is created, assigned, commented on, completed or deleted.

• Zoom recordingsread-only: yes
  • cloud_recording:read:list_user_recordings
  • cloud_recording:read:list_recording_files
  • cloud_recording:read:meeting_transcript
  • meeting:read:summary

  Allows (in plain terms): Zoom spells the verb into every one of these, and in all four it is read: list your cloud recordings, list the files inside a recording, read a meeting transcript, read a meeting summary.

  What we do: Reads transcript and summary text for meetings in your scan window. Nothing is scheduled, started, joined, recorded or deleted.

  Zoom's default bundle for this toolkit includes permission to schedule meetings and to delete a transcript. We refused all of it.

• Confluenceread-only: yes
  • read:page:confluence
  • read:space-details:confluence
  • read:content.metadata:confluence
  • offline_access

  Allows (in plain terms): Each of the first three begins with read: view a page, view a space's details, view content metadata. The last one keeps the connection alive between scans.

  What we do: Reads pages whose titles look like a process or an SOP, and stores the title, the body and any owner named on it as your process inventory. Only the titles are sent to the model. Nothing is created, edited, moved or deleted.

• Notionread-only: yes

  What we do: Reads only the pages you shared with TimeScout on Notion's own screen, and of those only the ones whose titles look like a process or an SOP. Nothing is created, edited or deleted.

  Notion has no per-permission scopes. You consent at the workspace level and pick which pages to share on Notion's own screen, so you decide the reach rather than a scope string.

• Google Workspace, company-wideread-only: yes
  • https://www.googleapis.com/auth/gmail.readonly
  • https://www.googleapis.com/auth/calendar.readonly
  • https://www.googleapis.com/auth/admin.directory.user.readonly

  Allows (in plain terms): The read-only form of each: view mail, view calendars, view the directory entry of a user. None of the three can change anything. Nobody sees a consent screen in this lane at all, because a super admin pastes the three lines on the left straight into their Google Admin console.

  What we do: Reads the same things a personal Gmail and Calendar connection reads, for the people the admin included, plus each person's directory entry so names match across sources; their org unit, job title and department are kept. Nothing is sent, changed or deleted. Everyone included is emailed a notice naming the admin who did it.

  Deleting that entry in the Google Admin console ends our access immediately.

• Microsoft 365, company-wideread-only: yes
  • Mail.Read
  • Calendars.Read
  • User.Read.All
  • Organization.Read.All
  • Chat.Read.All
  • ChannelMessage.Read.All
  • Team.ReadBasic.All
  • Channel.ReadBasic.All
  • Sites.Read.All

  Allows (in plain terms): Nine application permissions a Global Administrator grants once for the whole tenant: read mail, read calendars, read every user, read the organization, read Teams chats and channel messages, read the basic team and channel lists, and read SharePoint sites. Application permissions act as the app, not as a signed-in person, so they reach every mailbox the administrator later includes.

  What we do: For each included person: reads the whole mailbox for the scan window, Deleted Items, Archive and custom folders included, never Drafts, Outbox or Junk Email; calendar events; Teams chats once Microsoft approves it. The directory is read to offer the list of people; department, job title and manager's address are kept. Channel messages and SharePoint are consented, not read yet. Nothing is sent, changed or deleted.

  Removing TimeScout under Enterprise applications in the Microsoft Entra admin center ends our access immediately. Everyone included is emailed a notice naming the administrator who did it.

• Zoom, company-wideread-only: yes
  • cloud_recording:read:list_user_recordings:admin
  • cloud_recording:read:list_recording_files:admin
  • cloud_recording:read:recording_transcript:admin
  • user:read:list_users:admin
  • meeting:read:summary:admin

  Allows (in plain terms): Five account-level permissions the Zoom account owner grants to an app they create in their own Zoom account: list any user's cloud recordings, list the files inside a recording, read a recording's transcript, read a meeting summary, and list the account's users. Account-level means they reach every person in the account, not only the owner.

  What we do: For the people the account owner included: reads cloud-recording transcripts and meeting summaries for meetings they hosted in the scan window. The user list is read to offer the list of people, and each included person's department is kept. Nothing is scheduled, started, joined, recorded, edited or deleted.

  You create the app yourself in the Zoom App Marketplace, so Zoom shows no consent screen. Deactivating or deleting that app under Manage in the Marketplace ends our access immediately. Everyone included is emailed a notice naming the account owner who did it.

• HighLevelread-only: yes
  • calendars.readonly
  • calendars/events.readonly
  • calendars/groups.readonly
  • campaigns.readonly
  • contacts.readonly
  • conversations.readonly
  • conversations/message.readonly
  • conversations/reports.readonly
  • forms.readonly
  • funnels/funnel.readonly
  • funnels/page.readonly
  • locations.readonly
  • locations/customFields.readonly
  • locations/customValues.readonly
  • locations/tags.readonly
  • locations/tasks.readonly
  • objects/record.readonly
  • objects/schema.readonly
  • opportunities.readonly
  • pipelines.readonly
  • surveys.readonly
  • users.readonly
  • workflows.readonly

  Allows (in plain terms): All 23 of these are read permissions, so none of them can change anything in your location. HighLevel offers a write counterpart for most of them and we asked for none.

  What we do: Reads your conversations and their messages, call transcripts included; your appointments and calendars; pipeline opportunities and their stage names; the contacts that work touches, with their tasks and notes; your team's names and email addresses; and the names of your workflows, funnels, campaigns, forms and surveys. TimeScout never writes to a HighLevel location: nothing is sent, booked, tagged, moved or deleted.

• Salesforceread-only: no
  • api
  • refresh_token

  Allows (in plain terms): Salesforce has no read-only API scope. `api` is the narrowest that can read anything, and Salesforce words it as access to your account over the APIs, so it permits writes. We never ask for `full`, which is wider still. `refresh_token` only keeps the connection alive between scans, and the setup we recommend never receives one.

  What we do: Reads your users, opportunities and stage history, leads, the calls, emails and meetings logged in your scan window, contact opt-out flags and Flow names, and stops rather than spend your API allowance. The scan has no code path that creates, edits or deletes a record; the read-only user you choose enforces that. Creating Agentforce agents is a separate permission, per org.

• iCloud Mailread-only: yes

  What we do: Makes IMAP read calls for the messages in your scan window, fetched without marking them read. Nothing is sent, moved or deleted, and the password is stored encrypted.

  No OAuth. You paste an app-specific password you create at appleid.apple.com and can revoke there, and we make IMAP read calls with it. We store it encrypted.

• Yahoo Mailread-only: yes

  What we do: Makes IMAP read calls for the messages in your scan window, fetched without marking them read. Nothing is sent, moved or deleted, and the password is stored encrypted.

  No OAuth. You paste an app password you create at login.yahoo.com under Account Security and can revoke there, and we make IMAP read calls with it. We store it encrypted.

• Fastmailread-only: yes

  What we do: Makes IMAP read calls for the messages in your scan window, fetched without marking them read. Nothing is sent, moved or deleted, and the password is stored encrypted.

  No OAuth. You paste an app password you create at app.fastmail.com under Settings, Privacy & Security, Integrations and can revoke there, and we make IMAP read calls with it. We store it encrypted.

• Zoho Mailread-only: yes

  What we do: Makes IMAP read calls for the messages in your scan window, fetched without marking them read. Nothing is sent, moved or deleted, and the password is stored encrypted.

  No OAuth. You paste an app password you create at accounts.zoho.com under Security, App passwords and can revoke there, and we make IMAP read calls with it. We store it encrypted.

• Email IMAP (Generic)read-only: yes

  What we do: Makes IMAP read calls for the messages in your scan window, fetched without marking them read. Nothing is sent, moved or deleted, and the password is stored encrypted.

  No OAuth. You type your provider's IMAP host and an app password, we make IMAP read calls with it over TLS only, and we store it encrypted. Proton Mail and Tuta cannot be connected this way: neither offers server-side IMAP.

• Firefliesread-only: yes

  What we do: Makes read calls for meeting titles, participants and transcript text in your scan window. Nothing is created, shared or deleted.

  No OAuth. You paste your own API key, we make read calls with it, and we store it encrypted. Deleting the key at Fireflies ends our access.

• Rampread-only: yes
  • business:read
  • entities:read
  • users:read
  • bills:read
  • transactions:read
  • reimbursements:read

  Allows (in plain terms): Each scope is Ramp's read grant for one object family: the business, its legal entities, its users, its bills, its card transactions and its reimbursements. None of the six can create, approve, pay, edit or delete anything; the write grants are separate scopes we never ask for.

  What we do: Reads your entities, who is on Ramp (names and roles, never an email), bills with their approval and payment state, card charges with whether a receipt and memo are attached, and reimbursements, to measure what waits on an approval, what is overdue and what has no receipt. No card number, receipt image or bank account number is read; document links are not kept; nothing writes to Ramp.

  No OAuth login. You create an app in your own Ramp (Company → Developer) with the Client Credentials grant and only these read scopes, and paste its client id and secret; we store the pair encrypted, mint a token per scan and never store the token. Deleting the app in Ramp ends our access.

• Mercuryread-only: yes

  What we do: Reads your accounts (names only), transactions with their status and counterparty name, and send-money approval requests, to measure what waits on an approval and what moved. Account and routing numbers are discarded, never stored; a counterparty's bank details are not kept; nothing is sent, and no recipient is created. We ask for a READ-ONLY token, and Mercury itself downgrades an unused write token.

  No OAuth. You create a read-only API token under Settings → Tokens and paste it; we store it encrypted. Deleting the token at Mercury ends our access.

• Striperead-only: yes

  What we do: Reads your payments and which failed, your invoices and collection attempts, your subscriptions, refunds, disputes and payouts. We never open your customer list. Any billing name, email, phone or address on a payment, invoice or dispute is dropped before we store it, with the card's last four and expiry. We keep the card's brand, how it was paid, and your metadata as you wrote it. Nothing is charged or refunded.

  No OAuth. You create a RESTRICTED key in Stripe (Developers → API keys → Create restricted key) with every permission we ask for set to Read and everything else None, and paste it; we store it encrypted. We refuse a full secret key and a test-mode key. Deleting the key at Stripe ends our access immediately.

• Hyrosread-only: yes

  What we do: Reads your leads with the traffic source, campaign and ad that brought each one, your sales with their amount, currency, product and whether each was refunded, and your booked calls with how each went. A lead name is dropped before our copy of the row is written; their email and phone are stored encrypted beside it, never in plain text. We never create, edit or delete anything in Hyros.

  No OAuth. You create an API key in Hyros with a role that can read leads, sales and calls, and paste it; we store it encrypted. Deleting the key at Hyros ends our access.

• Supabase (your app's database)read-only: yes

  What we do: Reads the shape of the database you point us at: your table names, the columns in each table with their types, row counts, when a table was last written to, and the foreign keys that say what relates to what. We read a small sample of rows per table, redacted before anything is stored. We never read your auth users, your secrets or your storage objects, and no code path writes.

  No OAuth. You create a read-only role in your own SQL editor with the snippet we give you, then paste that role's connection string; we store it encrypted. The connect check proves the role cannot create a table or update a row, and a role that can is refused rather than stored. Dropping the role in Supabase ends our access.

• GitHub (synced app code)read-only: yes

  What we do: Reads ONE repository you name: its default-branch file list and the source files in it, to inventory the app's screens, the forms on them and the Supabase tables each one reads and writes. Nothing is pushed, no other repository is opened, and issues, pull requests, Actions, secrets and environment variables are never read. The parse is code, so no file is sent to a model.

  No OAuth. You create a fine-grained personal access token in GitHub scoped to that one repository, with Contents set to Read-only and nothing else, and paste it; we store it encrypted. A token that can push is refused. Deleting the token in GitHub ends our access.

• Meta Adsread-only: yes
  • ads_read
  • read_insights

  Allows (in plain terms): ads_read lets an app read the ad accounts your system user is assigned: your campaigns, ad sets and ads, their budgets and status, the audiences an ad set targets, and the creative on each ad. read_insights lets it read how they performed: spend, impressions, clicks and results. Neither one can change or delete anything. That is a third permission, ads_management, which we refuse.

  What we do: Reads your ad accounts, campaigns, ad sets and ads: names, budgets, status, spend, results, and what somebody has to fix, such as a disapproved ad or an account that stopped delivering. We never read Lead Ads submissions, never open an ad's creative, never read your audiences, and never read the card behind an account. No code path writes: nothing is created, paused, edited or deleted.

  No OAuth. You create a System User in your own Meta Business Settings, assign it the ad accounts with View performance, and generate a token with only ads_read and read_insights; we store it encrypted. We refuse a token that carries ads_management. Deleting the token or the system user ends our access.

• Makeread-only: yes

  What we do: Reads the names of your scenarios and the steps inside them, as your automation inventory. Nothing is run, changed or deleted.

  No OAuth. Your own API token, read calls only, stored encrypted.

• n8nread-only: yes

  What we do: Reads the names of your workflows and the steps inside them, as your automation inventory. Nothing is run, activated, changed or deleted.

  No OAuth. Your own API key against the instance URL you give us, read calls only, stored encrypted.

• HubSpotread-only: yes

  What we do: Reads your workflow names and steps as your automation inventory, your team by name and email address, your deals with pipeline and stage, the headers of calls, emails and meetings (time, direction, outcome, who owns it) and the contacts they touch with their opt-out flags. Email text is read for a sample only. We keep our own copy of what we read, a contact address encrypted at rest. Nothing in HubSpot is changed.

  No OAuth. A private-app token you create with read permissions for your owners, contacts, deals and deal pipelines, plus your automation inventory; the sales email text is a separate one you can leave off, and the scan says what it cannot measure without it. Read calls only, stored encrypted. Deleting the private app in HubSpot ends our access.

• Process Streetread-only: yes

  What we do: Reads your workflow and checklist names and the steps inside them, as your automation inventory. Nothing is run, changed or deleted.

  No OAuth. Your own API key, read calls only, stored encrypted.

• Zapierread-only: yes

  What we do: Reads the export file you upload, and nothing else. We hold no Zapier credential, so there is no account of yours for us to reach.

  We hold no credential at all. You export your Zaps from Zapier and upload the file, so nothing connects and nothing is read on your account.

• Otter notification emailsread-only: yes

  What we do: Reads the Otter notification emails already sitting in a mailbox you connected. There is no access to your Otter account at all.

  No connection of its own. Otter transcripts reach us through the notification emails Otter sends to a mailbox you already connected.

• Read AI notification emailsread-only: yes

  What we do: Reads the Read AI notification emails already sitting in a mailbox you connected. There is no access to your Read AI account at all.

  No connection of its own. Read AI transcripts reach us through the notification emails it sends to a mailbox you already connected.

• iMessageread-only: yes

  What we do: The desktop app reads the local database on your Mac and uploads only the chats you picked. Nothing on our servers can reach your Mac, and nothing is ever sent from your account.

  No OAuth and no server-side access. The desktop app reads the local database on your Mac, and only the chats you pick are uploaded.

• WhatsAppread-only: yes

  What we do: The desktop app reads the export or local database you point it at and uploads only what you picked. Nothing on our servers can reach your device, and nothing is ever sent from your account.

  No OAuth and no server-side access. You import a chat export or the local database through the desktop app, and only what you pick is uploaded.

• Telegramread-only: yes

  What we do: The desktop app reads the export file you point it at and uploads only what you picked. Nothing on our servers can reach your device, and nothing is ever sent from your account.

  No OAuth and no server-side access. You import a Telegram export through the desktop app, and only what you pick is uploaded.

• Desktop screen activity (Screenpipe bridge)read-only: yes

  What we do: Receives what the bridge on your own machine sends us: app names, window titles, samples of on-screen text read by OCR, and excerpts of meeting transcripts. We install nothing and run nothing on your machine, and we cannot ask the bridge for more than you pointed it at. Revoking its key stops the stream.

  No OAuth and nothing installed on our side. The bridge runs on your own machine and sends us what you point it at, using a key you create and can revoke in Settings. Revoking it stops the stream.

• Mobile activityread-only: yes

  What we do: Nothing. There is no way to connect a phone today and no code that reads one.

  Not built. The name is reserved in our source list, there is no way to connect a phone today, and nothing is read.

The analysis is done by large language models, so your message text leaves our servers. Today it goes to Anthropic's Claude models, reached through the OpenRouter gateway; both are listed as sub-processors below.

• Your message content is sent to Anthropic's Claude models — The analysis is LLM work, so message text leaves our servers — directly to Anthropic, or via OpenRouter on bring-your-own-key and per-user credit lanes. Prompts carry display names and a recipient count, not raw addresses.
• The analysis stays yours — Roles, patterns and opportunities are stored to your account. Teammates see your aggregates only if you turn sharing on — never your raw messages.
• We do not sell data or train models on it — Your content produces your results. It is not sold, and TimeScout trains nothing on it.

• Raw messages age out automatically — A daily job deletes message bodies after a fixed window (the live window is on the privacy page). What the scan produced — roles, patterns, opportunities — is kept: that is the product.
• Deleting your account deletes the data — One click in Settings removes your messages, scans and connections, revokes the OAuth grants, and deletes your records at our vendors. Only the Stripe payment ledger is retained.
• You can stop at any time — Disconnect a source and we stop reading it. Nothing re-connects on its own.

The live window today: 30 days after a scan finishes, a daily job deletes the message bodies and their embeddings — email text, chat text and voice transcripts — from our database. Headers and counts (sender, subject, date, how many) stay so your stats and history still add up, and everything the scan produced — opportunities, roles, patterns, and the short evidence snippets shown in the app — is kept, because that is the product.

Messages we classify as noise (newsletters, marketing, automated notifications, large broadcast channels) keep only their header and count — we do not retain their bodies.

Process documents and automation definitions are different, and the policy above does not cover them. They are your inventory rather than a message someone sent you, so we keep them. Disconnecting that source stops new imports, and what was already imported stays until you delete your account or ask us to remove it.

One practical effect, so it is not a surprise: if you come back after your raw window has passed, the next scan is a full scan rather than an incremental one, and the app says so. Opening a source from an older agent shows "source expired under retention" with the date it was deleted.

These are the companies that receive customer data on our behalf. Each one is listed with what it does and where it runs.

• Vercel

  Hosts the web app and its API routes

  United States · since 2026-08-01

• Supabase

  PostgreSQL database holding everything TimeScout stores

  United States (us-east-1) · since 2026-08-01

• Railway

  Runs the scan worker that ingests and analyses your data

  United States · since 2026-08-01

• Clerk

  Authentication and session management

  United States · since 2026-08-01

• Composio

  Holds the OAuth grants and fetches your Gmail, Outlook, Slack, Calendar, Zoom, Teams, Asana, Notion and Confluence data

  United States · since 2026-08-01

• Google (Workspace APIs)

  Reads Gmail, Calendar and the directory entry of the people a Workspace admin includes, when a company connects that way

  United States · since 2026-09-07

• OpenRouter

  Gateway that model calls transit on BYOK and per-user credit lanes (the shared lane goes to Anthropic directly since 2026-08-20)

  United States · since 2026-08-01

• Anthropic

  Claude models that analyse message content

  United States · since 2026-08-01

• Resend

  Sends transactional email (scan started, scan complete, receipts)

  United States · since 2026-08-01

• Intercom

  Customer support inbox and the in-app chat widget

  United States · since 2026-08-01

• Stripe

  Payments and credit top-ups

  United States · since 2026-08-01

• Sentry

  Server-side error reports from the app and the scan worker, scrubbed before they are sent

  United States · since 2026-08-01

• PostHog

  Product analytics: an opaque account id and short labels such as a source name or a scan outcome

  United States · since 2026-09-07

All of it runs in the United States today. If you need EU data residency, tell us before you connect anything — it is a deployment decision, not a setting.

These load without asking, because the product cannot work without them (strictly necessary):

• Clerk — Signs you in and keeps your session. Authentication is the service. Without it there is no account, no scan and no way to protect anyone's data, so it loads before any consent question can be asked.
• Cloudflare Turnstile — Bot check on the sign-in screen. Part of the sign-in flow itself — it exists to stop credential-stuffing against accounts, not to profile visitors.

These wait for you:

• Intercom Messenger — In-app chat with our support team. Useful, but the site works without it — so it loads only after you open chat or consent, and never before.
• PostHog (in your browser) — Counts which pages you open, and notices when something breaks: a page that throws an error, one of our own buttons whose request comes back refused, or three clicks in the same spot when nothing happened. This is the part that runs IN your browser, and it is the part this consent gate governs: in the EU, EEA, UK and Switzerland it never loads at all, and anywhere else it is off the moment your browser sends Do Not Track. It never records your screen and never reads the page. When something breaks we send the error text and where in the code it came from, the address of the page you were on with any private part of it removed, and for a refused request the name of the request and the number it answered with — never a screenshot, never the contents of the page, and never who you were writing to. A click tells us only where on the screen it landed, never what you clicked. One honest limit, because we would rather say it than promise more than we can check: an error's text is written by whichever piece of code failed, so before it is sent we take out anything that looks like an email address or one of our internal contact identifiers and cut it short — but it is not a fixed list of words we control, and a future error could in principle repeat something it was working on, such as the subject of a message. None of the errors this app can raise today does that. Counting what happens in your ACCOUNT is a separate thing, described below — this entry is only about the code that would run on your device.

In the EU, EEA, UK and Switzerland the Intercom chat widget stays unloaded until you open it — clicking “chat with us” is what loads it, and that click is consent to chat and nothing else. Product analytics is stricter: in those countries it never loads in your browser at all, whatever you have clicked. We run no advertising trackers anywhere, and nothing here follows you to other websites.

Separately from anything that runs on your device, we count what happens in your account on our own servers:

• Product events (our servers) — Counts what happens in your account: a scan starting, finishing or failing, a source connecting, a report being opened, an agent being marked done. We record these ourselves, about your account, to know whether the product works — a legitimate interest in running it, not advertising or profiling. What we send is an account id (a random string, not your email or your name) and short labels like "gmail", "180" or "dismissed". Never an address, never a name, never a subject line, never anything from a message. It is not affected by the consent choice above, because it does not run on your device; if you would rather we did not, ask us and we will stop it for your account. One detail worth knowing: if you share your report link and somebody opens it, that counts as a view on YOUR account, and we learn nothing about who opened it.

You can ask for a copy of what we hold, ask us to correct it, or ask us to delete it. You can delete your account yourself from Settings, which erases your data here and at our sub-processors.

If you are one of the people a TimeScout customer corresponds with and you want to know whether your details appear in their data, write to us at the address below and we will check.

TimeScout's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Privacy questions and data requests go to customersupport@timescout.ai. We answer within 30 days.

• Everything is encrypted in transit with TLS.
• The database is encrypted at rest, and on top of that every access token, refresh token, API key and mail password we store today is encrypted again by the application with AES-256-GCM before it is written. Older plaintext credential columns are still on the table and nothing writes to them any more; they are being migrated out.
• The database denies access by default. Every table refuses reads and writes unless the application asks for them.
• Staff access is two named roles with a capability check on every action, and every one of those actions is written to a log the database itself will not let anyone edit or delete.
• We cut message text down before it reaches a model. Prompts carry a display name and a count of recipients, not raw addresses.
• Correspondents are replaced with a keyed hash once a scan finishes. That is a pseudonym, not anonymity: it is still personal data, we treat it as such, and we never claim otherwise.
• Messages we classify as noise never have their bodies stored at all.
• Raw message bodies are deleted on the window described above.

Where we stand: there is no SOC 2 report yet. Our controls are written down and we run them, and we are collecting data processing agreements from the vendors listed above. When there is a report we will say so here rather than implying one.

If we confirm a breach that involved your data, we email you without undue delay and no later than 72 hours after we confirm it. The email says what happened, what was affected, and what we are doing about it. If we do not yet know all of that, we tell you what we know by then and follow up.

We email every account holder at least 14 days before a new sub-processor starts processing customer data, and we update the table above at the same time. If you do not want the change, you can delete your account before it takes effect.

If TimeScout is sold, merged, or its assets transferred, your data stays under this policy until it is replaced by a policy you have been told about. We email account holders before any transfer, and you can delete your account first.

• Disconnect any source. We stop reading it immediately, and nothing reconnects on its own.
• Export everything we hold about you as a file, from Settings.
• Delete your account, which erases your data here and at our sub-processors.
• Ask us for a copy of what we hold, ask us to correct it, or ask us to delete part of it, at the address above.

We are preparing a data processing agreement with standard contractual clauses for transfers outside the EU. It is not ready yet. Until it is, this policy is our complete statement of how we process your data, and you can ask us at the address above for the expected date.

Every change to this policy is listed here, newest first, and the date at the top of the page is the date of the newest entry.

• 2026-09-15: Google Workspace company connections now keep each included person's job title and department, as the administrator entered them in the Workspace directory, alongside the org unit path kept since 2026-09-14. Both were already in the directory entry the administrator authorized us to read; we now ask for the full entry instead of the short one. No new permission is requested.
• 2026-09-14: A company connection now KEEPS what your own directory says about each person the administrator included, where before it read that entry only to draw the list and match names. Microsoft 365 keeps a department, a job title and the address of the person's manager; Google Workspace keeps the org unit path; Zoom keeps a department. It is stored on that person's row under the connection, dies with the connection, and is what will draw your org chart. The department, title and org unit were already in the directory answer we asked for; the manager is a new ask on that same call, under the read-every-user permission your administrator already granted. No new permission is requested.
• 2026-09-11: Added Zoom, company-wide, to the connector list: a Zoom account owner creates a Server-to-Server app in their own Zoom account and includes people, and TimeScout reads their cloud-recording transcripts and meeting summaries with the five account-level read permissions listed. Announced ahead of the connect screen shipping; a Zoom you connect yourself is unchanged.
• 2026-09-11: Corrected what the HubSpot row says. One private-app token serves both the workflow inventory and the CRM read, and the row described only the first while saying no contact, deal or email data was read. It now names the owners, deals, engagement headers and contacts the CRM read has been reading, says email text is sampled, and says we keep our own copy of those records with a contact address encrypted at rest.
• 2026-09-09: Gmail scans now read your Trash as well as everything else in the window, so mail you read and deleted still counts as work; Spam is never read. Applies to Gmail connected by you and to mailboxes included through a Google Workspace.
• 2026-09-09: A mailbox included through your company's Microsoft 365 is now read whole for the scan window: Deleted Items, Archive and every custom folder included, so mail you read and deleted still counts as work. Drafts, Outbox and Junk Email are never read. An Outlook you connect yourself still reads Inbox, Sent and Archive only. Added the Microsoft 365 org connect and its nine permissions to the connector list.
• 2026-09-09: Published what every permission we request would ALLOW beside what TimeScout actually does with it, and marked which of those lines are the provider's own words rather than our summary. Corrected the data processing agreement section: we do not have one yet, and the old text offered it on request.
• 2026-09-09: Narrowed what Gmail asks for from eleven scopes to three: your mail, your email address and your profile. The contacts, birthday, phone and address reads are gone. Accounts connected before this date keep the wider grant until they reconnect.
• 2026-09-09: Named every connector we can read today, published the exact permissions each one asks for, added a 72-hour breach notice and 14 days' notice before a new sub-processor, and named the company and its address. Added Sentry, PostHog and Google to the sub-processor list.
• 2026-08-20: Rewrote the policy to describe the pipeline that actually runs. Dropped a file connection we never had and a promise about model providers that was not ours to make.