Skip to content

Privacy Policy

Last updated August 15, 2026

Ray works inside your team’s chat. That means it handles real team conversations, so this page is specific about what it reads, what it keeps, who processes it, and how you delete it. Ray is operated by Mark Skrypka, trading as Creako Labs (“we”, “us”). Questions: support@heyray.io.

What Ray reads

Ray sees messages in the channels and threads it has been invited to, and direct messages sent to it. It cannot see channels it isn’t a member of. When someone asks about a file shared in those conversations, Ray opens that one file to answer. It never browses files on its own, and file contents are not stored. Most integrations are connected per person: each teammate links their own account (an issue tracker, email, a calendar), and Ray acts on that tool as the person asking, with their access. A few tools offer no per-person login, and those connect once with a single workspace key that covers the whole team. Anything consequential — creating a ticket, sending an email — happens only after someone on your team approves it, and then runs from the approver’s connected account.

What Ray stores

  • Conversation context. Ray keeps the threads it actually participated in — the messages it engaged with and its own replies, plus rolling summaries of long threads — so follow-ups make sense. It does not archive your workspace: messages Ray stayed out of never enter durable storage (a short-lived context window, minutes-scale, is covered below).
  • Team memory. Durable facts your team tells Ray or that it learns from conversations it engaged in (preferences, constraints, who owns what), stored with embeddings so it can recall them later. Memory can be switched off by an admin at any time; corrections supersede rather than silently overwrite.
  • Action history. A record of the actions Ray performed (tool, title, a pointer to the created artifact) so it can answer “what did you do?” honestly.
  • Schedules and settings. Digest schedules, reminders, timezone, admin list, and the memory switch.
  • Governance records. A content-free audit trail of sensitive events (installs, approvals, admin changes, purges) — identifiers and hashes, not message text.
  • Billing state. Your plan and monthly task counts. Card details never touch our systems — payment runs entirely through Stripe.

How long it’s kept

Stored conversation context and team memory have no automatic expiry — they persist until your team deletes them (below) or uninstalls Ray. We’re explicit about this because it’s what makes Ray useful: an assistant that forgets your conventions every week isn’t a teammate. Around that durable core, the operational stores are short-lived:

  • In-flight coordination state (message buffers, recent-context windows, pending approvals) and platform caches (channel names, member display names and avatars) live in Redis with TTLs from seconds to a few days and clean themselves up.
  • Run records on our task infrastructure (Trigger.dev) — including debugging snapshots of what Ray was shown for a turn — expire with the platform’s retention window, at most 30 days.
  • Product analytics are metadata only — token counts, latency, cost, feature and model names. Message content is never sent to analytics.

Who processes it

Ray is built on infrastructure and AI providers. The list is short and deliberate; each receives only what its job requires:

  • OpenAI — runs Ray's reasoning model (the conversations, memory, and tool results Ray works with), reads the images and documents you ask Ray to look at, and generates memory embeddings.
  • Google (Gemini) — decides whether Ray should respond to a message, extracts memory facts, summarizes long threads, and watches the video or audio you ask Ray to look at.
  • Anthropic — alternate reasoning model route, used only if we switch Ray's model — listed so the list stays true if we do.
  • Composio — executes integration actions and holds the OAuth tokens for the tools you connect.
  • Exa — web search queries, only when Ray searches the web.
  • Slack — the platform Ray lives in.
  • Neon (Postgres) — stores conversation context, memory, actions, schedules, and settings.
  • Upstash (Redis) — short-lived coordination state and the encrypted Slack workspace token.
  • Vercel — receives workspace events in transit (webhooks and web pages).
  • Trigger.dev — runs Ray's background work; run records expire within at most 30 days.
  • PostHog (EU) — product analytics — metadata only, never message content — and, only for visitors who accept, website analytics and session recording on heyray.io.
  • Stripe — billing only — we never see card details.

Our AI providers process conversation content to generate Ray’s responses under API terms that do not permit using your content to train their models. We don’t sell your data, show ads, or train models of our own on it.

Where it’s stored

Everything durable (conversation context, team memory, action history, schedules, settings) is stored on Neon in AWS US East. Product analytics run on PostHog’s EU cloud. The short-lived coordination state described above runs on Upstash. Our AI providers process requests on their own infrastructure, and we don’t control which region they use. We don’t offer a choice of data region today, so if your team needs one, ask us before you install rather than after.

Deleting data

  • One fact: tell Ray to forget it (“Ray, forget that”). Retired memories stop being used immediately.
  • Everything: a workspace admin can ask Ray to purge all stored memory and conversation context. Because it’s irreversible, the purge asks for an in-channel approval first, visible to the team.
  • Memory off: an admin can switch durable memory off — Ray keeps working in the moment but stops remembering across conversations, and existing memory stays paused, not consulted.
  • Uninstall: removing Ray from your workspace stops all processing immediately, revokes integration connections at the tools themselves, and deactivates schedules. Stored workspace data is deleted after a 30-day grace window; reinstalling within that window cancels the deletion. The content-free governance trail survives as our record that the deletion happened.

Integration credentials

When a teammate connects a tool, the credential is held by Composio, our integration provider. For most tools that is an OAuth token scoped to that individual person within your workspace, and they can disconnect it at any time by asking Ray. A few tools offer no per-person login and take one workspace key instead. An admin or the person who connected it can disconnect that, and because it belongs to the workspace rather than to them, it stays in place if they leave, with a prompt to your admins to rotate it. When a teammate is deactivated in Slack, their own connections are revoked at the tool itself. Your Slack workspace token is stored encrypted (AES-256-GCM) and deleted when you uninstall. Credentials are never placed in model context.

Google user data (Google Ads)

Teams can connect Google Ads to Ray through Google sign-in, and Google holds that connection to a specific disclosure bar, so this section states exactly how Ray accesses, uses, stores, shares, and protects Google user data.

  • What Ray accesses. When a teammate connects their Google Ads account, Ray can read campaign data — campaigns, budgets, ad groups, ads, keywords, and account metadata such as the account name, currency, and timezone — and can create campaign structures in that account.
  • How Ray uses it. Only to fulfill what your team asks for in chat: answering questions about your campaigns and drafting the campaign structures you request. Every write is shown on an approval card first and runs only after a teammate approves it, and new campaigns are always created paused: nothing spends until someone enables it in Google Ads itself. Google user data is never used to develop, train, or improve AI models — ours or our providers’.
  • What Ray stores. Ray does not keep a copy of your Google Ads data. What persists is the conversation itself (what Ray said in your channel) and the action history described above — a pointer to what was created (a campaign id and its name), not campaign contents or performance data. Account details like currency are fetched live when a card needs them and are not stored.
  • Who Ray shares it with. Data read from Google Ads is processed by our AI providers to generate the response you asked for, under the same no-training API terms as everything else on this page, and by the subprocessors listed above in their stated roles — no one else. It is never sold, never used for advertising or profiling, and never transferred to any third party for any purpose beyond answering your team.
  • Tokens and revocation. The OAuth token is held by Composio, scoped to the individual teammate who connected (see Integration credentials). Disconnect by asking Ray, or revoke Ray’s access directly at myaccount.google.com/permissions — either way the grant is revoked at Google, not just forgotten on our side.

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

How sensitive data is protected

The mechanisms below apply to everything Ray handles — workspace conversations, integration data, and Google user data alike.

  • Encryption in transit. Every connection — between your chat platform and Ray, between Ray and the tools it acts on (Google Ads included), and between Ray and every subprocessor listed above — uses TLS. Nothing travels in the clear.
  • Encryption at rest. Stored workspace data (conversation context, memory, action history, schedules, settings) lives in a database whose storage is encrypted at rest. Your Slack workspace token is additionally encrypted at the application layer (AES-256-GCM) before it is stored.
  • Credential handling. Integration OAuth tokens (Google Ads included) are held in Composio’s credential store, scoped to the individual teammate who connected. They are never written to our own database, never logged, and never placed in model context.
  • Workspace isolation. Every stored table is partitioned by workspace and enforced with database row-level security that the application’s runtime role cannot bypass — one workspace can never read another’s data, even in the presence of an application bug.
  • Access control. There is no standing human access to your content in the normal operation of the service. Sensitive actions inside your workspace (sending email, creating tickets, campaign changes) additionally require a teammate’s explicit approval before they run.
  • Retention and deletion. The retention windows and deletion levers above apply to sensitive data with no exceptions: per-person disconnect at any time with revocation at the tool itself, and full workspace deletion after uninstall’s 30-day grace window.
  • Incident response. If we learn of a security incident affecting your data, we notify affected workspaces without undue delay at the contact we have for them, with what happened and what we did about it.

Cookies on this website

Everything above is about Ray inside your chat, where nothing is stored on your device at all. This section is about heyray.io, the website.

  • One cookie we set regardless. Starting an install puts a short-lived random value in a cookie named ray_install_state and checks it when Slack sends you back. It is what stops someone else from starting an install in your name. It lasts ten minutes, cannot be read by scripts, and identifies nothing about you, so we do not ask permission for it.
  • Analytics, only if you accept. If you accept, we load PostHog, which counts page visits and records browsing sessions so we can see which parts of the site lose people. It stores an identifier for your browser for up to a year, in a cookie beginning ph_ and in local storage. Anything you type is masked before a recording leaves your browser, so form fields are never readable in a replay. Requests go to heyray.io/ingest, which forwards them to PostHog’s EU servers. We route them through our own address because ad blockers drop requests sent to analytics domains by name, not to disguise who receives them. If the link that brought you carried campaign tags (the utm kind, or a ref or via code), those tags and the page you landed on are kept for 30 days in a cookie named ray_attrib, so that an install can be credited to the channel that brought you. Tags only, never anything about you.
  • Your answer itself. Whichever you choose is remembered in your browser’s local storage under ray_consent, so we stop asking. It never reaches our servers.

Decline and none of it loads. Not a cookie-free fallback, not anonymous counting: PostHog is never started, so nothing is stored and no request is made. You can change your mind either way through Cookie choices at the bottom of any page, which also deletes what PostHog stored while you allowed it. We use no advertising or cross-site tracking cookies anywhere.

Your rights

Depending on where you are, you may have legal rights to access, correct, export, or erase personal data. The controls above cover the common cases instantly; for anything else, email support@heyray.io and we’ll handle it directly.

Changes

If we make material changes — a new subprocessor, a new data store — we’ll update this page and the date above.