Sign up Back to home

Privacy Policy

Last updated October 16, 2026

This Privacy Policy explains what personal information Joshua Klimek, doing business as ActiveQ (“ActiveQ”, “we”, “us”) collects through the activeq.app website, the ActiveQ waitlist, the ActiveQ application at app.activeq.app and the customer portals and workspaces served from activeq.app addresses (together, the “Services”), how we use it, and the choices you have. It covers three groups of people: visitors and waitlist members; people who create or use an ActiveQ workspace (“account holders”); and people who contact a business that uses ActiveQ for support (“requesters”). Section 10 explains our different role for each.

1. What we collect

2. How we use it

We will not use waitlist emails for unrelated third-party marketing. If we send you marketing about ActiveQ, you can opt out at any time.

3. Who we share it with

We share information only with service providers that help us run ActiveQ, and with others when required by law or to protect rights, safety and security. If ActiveQ is transferred to a company or successor entity, your information may transfer with it. Our service providers today are:

If your workspace uses the API or webhooks, the workspace data in API responses and webhook messages goes to the systems the customer chooses, as described in section 10. Those recipients are not our service providers.

Integrations you connect. When a customer connects ActiveQ to an automation service such as Zapier, Make or n8n, the customer directs us to send that service the data its automations select. For the Zapier app, accepting the invite adds the app to the customer’s Zapier account and sends no data. Data flows only after an administrator approves the connection in the customer’s ActiveQ workspace, and the connection’s access token is then held by Zapier in the customer’s Zapier account. For Make and n8n, data flows through an API key the customer creates or a webhook endpoint the customer adds. That service is the customer’s processor, not our sub-processor, and it is not on the list above. What it does with the data is governed by the customer’s agreement with it. The customer is responsible for choosing it, for its terms and for having the right to send the data there. The customer can stop the flow at any time by disconnecting the connection in Settings > Integrations, revoking the key, switching off the Zap or deleting the endpoint.

Customer content is sent to an AI provider only when a staff member runs an AI action, as described in section 11. If you are an account holder, the businesses you invite and the people you give access to can see the information you put in your workspace, according to the roles you set. We will update this list when it changes.

4. Retention

We keep waitlist information until you ask us to delete it, or until we determine the waitlist is no longer needed, then delete it. Individual site analytics events are kept for up to 90 days. We may keep aggregated statistics (for example, page-view counts per day) for longer; they do not identify individual visitors. Account, workspace and requester information, including tickets, messages, attachments, knowledge base articles with their versions, article views and votes, and audit-log entries, is kept while the workspace exists. A deleted knowledge base article stays in the workspace’s trash, where it can be restored, and is removed on request (see section 6). We do not have a fixed retention period or automatic purge for it: removal happens on request (see section 6). A workspace owner can download a copy of the workspace’s data themselves (section 10). We do not offer self-service deletion of a whole workspace, so ask us by email. A data export file is kept in our file storage (Cloudflare R2) for 7 days and is deleted from our storage when the link expires, by a scheduled clean-up that retries a failed deletion. The database record of an export (who asked, when, its status and size) is deleted after 90 days, and we keep a record of the request in the workspace’s audit log, which is kept while the workspace exists. Original inbound emails stored as files are deleted automatically after 90 days; the text of each message remains in its ticket. The output of an AI action is deleted after 30 days by a scheduled clean-up that we run on a best-effort basis, so a failure could delay deletion; the other AI records described in section 11 are kept while the workspace exists. Session records are kept for 90 days after the session ends and then deleted. Webhook delivery logs (the message body, request headers without the signature, and the first 1 KB of the receiver’s response) are deleted after 30 days. API usage counts (requests and errors per key and hour) are deleted after 90 days. Idempotency records for API writes are deleted after 24 hours. The record of an app connection is kept while the workspace exists, and the hashes of its authorization codes and tokens are deleted 7 days after they expire or are revoked. These clean-ups run on a best-effort basis, and webhook bodies and delivery logs can contain personal data of a customer’s contacts until they are deleted. Sign-up request records, including the source of the visit and the optional “how did you hear about us” answer, are kept as long as needed for security and recordkeeping. Links in emails expire (request links after 72 hours) and expired link records are cleaned up automatically. Daily database backups are enabled, and deleted data may remain in a backup until that backup expires (currently the seven most recent daily backups are kept). Server logs and email delivery logs are kept by our hosting and email providers under their own retention practices. We may keep information longer where the law requires or to resolve disputes.

5. Cookies and local storage

The marketing pages on activeq.app do not set cookies and we do not use advertising or cross-site tracking. Our site analytics is run by us on our own site, uses no cookies and no browser storage, does not follow you to other sites, and sends nothing if your browser sends a Do Not Track or Global Privacy Control signal. The only item the marketing pages save on your device is your Night/Day theme choice, in your browser’s local storage, which you can clear at any time. When you use the application or a portal we set cookies that are strictly necessary: sign-in cookies that keep you signed in (a short-lived access cookie that is renewed, and a refresh cookie that lasts up to 30 days, or 12 hours for ActiveQ operators), and a device cookie, __Host-aq_dev, that identifies the browser so that we can tell a new sign-in from a returning one and enforce the limit of one live desktop and one live phone session per seat (strictly necessary for security; it lasts up to 400 days and is not used for advertising or tracking), and short-lived cookies used while signing in, plus portal session and return-address cookies on portals. They are not used for advertising or tracking. The application also saves, in your browser, your theme, the last queue view you used, and unsent reply drafts, and uses session storage while you sign up; none of this is sent to us. The sign-up and some sign-in pages load Cloudflare’s Turnstile bot check from Cloudflare, which is described in Cloudflare’s own privacy policy. Because we only use strictly necessary cookies and storage, there is no cookie banner. Our hosting provider may apply strictly necessary security measures to deliver and protect the Services.

6. Your choices, rights and deletion requests

A workspace owner can also download a copy of the workspace’s data without asking us (section 10). You can ask us to access, correct or delete your personal information, to remove you from the waitlist, or to close a workspace and delete its data, by emailing support@activeq.app with the subject “ActiveQ data request” from the address concerned. We may ask you to confirm you control it. We will respond within 30 days where practical, and always within the time the law requires. If you are a requester, the business whose support desk you contacted decides what happens to your tickets, so please contact that business first; we will help them act on your request. We send no marketing email today (the waitlist is not mailed). Any waitlist or marketing email we send in future will include a way to unsubscribe; account, sign-in and ticket emails are service messages that we send because you asked for them or because someone created or replied to a request involving you, and you can ask us to stop them by emailing us. Depending on where you live (for example California, other U.S. states with privacy laws, the EEA or the UK), you may have additional rights, such as to object to or restrict processing or to complain to a regulator. We will respond within the time the law requires and will not discriminate against you for exercising your rights. If we decline a request, you may appeal by replying to us with the subject “ActiveQ appeal”. Over the past 12 months we have not sold or shared personal information for advertising and do not use or disclose sensitive personal information beyond what is needed to provide the Services. The categories we collect are identifiers (name, email address, hashed IP address), account and commercial information, internet activity (analytics and logs), and content you submit, as described in section 1, for the purposes in section 2. For GDPR-style purposes, the legal bases we rely on are performing our contract with you, our legitimate interests in running and securing the Services, your consent where we ask for it, and legal obligations. We send ticket and account email as service messages. If we start sending marketing email, it will identify us, include our postal address and an unsubscribe link.

7. Security

We use reasonable measures to protect information, described on our Security page. No system is completely secure, and we cannot guarantee absolute security.

8. International transfers

We operate from the United States. Our database (Supabase) is hosted in the United States, in the AWS US East (N. Virginia) region. The website, application and portals run on Cloudflare’s global network, which processes requests in the data centers nearest to the person making them, so requests, logs and short-lived processing can occur in the United States and other countries. Files and original emails are stored in Cloudflare R2; we have not pinned them to a specific country or region. Resend sends our email and may process it in the United States and other countries. AI requests are sent to Anthropic, which we ask to process them in the United States where the model we use supports that. We do not promise that every copy of your information stays in one country. By using the Services you understand your information may be transferred to and processed in those countries. Where the law requires a transfer mechanism for personal data from the EEA, UK or Switzerland, workspace sign-up is currently limited to the United States; contact us before putting such data in a workspace.

9. Children

The Services are for businesses and are not directed to anyone under 18. We do not knowingly collect information from children. If you believe we have, contact us and we will delete it.

10. Customer data

The tickets, messages, files, contacts and other content that a workspace holds are the data of the organization that owns the workspace (the “customer”). For that content we act as the customer’s service provider (processor) and process it on its instructions to provide the Services; the customer decides what to collect from its requesters and is responsible for its own notices to them. For waitlist, account sign-up, analytics and security information described above, we decide how it is used.

Data processing terms. These terms apply to customer content that contains personal data and form part of the Terms. (a) We process it only to provide, secure and support the Services and on the customer’s documented instructions, which are the Terms, this policy and the customer’s use of the features and settings, unless the law requires otherwise. (b) People at ActiveQ who can access it are bound by confidentiality. (c) We use the security measures on our Security page. (d) The customer authorizes the service providers listed in section 3 as sub-processors. We will update that list before adding a new one that processes customer content, and the customer may object on reasonable grounds by emailing us, in which case it may stop using the Services. We stay responsible for our sub-processors and require them to protect the data. (e) We will help the customer respond to requests from people exercising their privacy rights, taking into account the nature of the processing. (f) We will tell the customer without undue delay after we become aware of a breach of security affecting its customer content. (g) A workspace owner can take a copy of customer content with the data export described below. On request when the workspace closes, we will delete or return customer content within a reasonable time, unless the law requires us to keep it, subject to backups as described in section 4. (h) On reasonable request we will give the customer the information needed to show we follow these terms, and we will allow reasonable assessments by it, at its cost and at a time we agree. (i) We do not sell customer content or use it for advertising. These terms do not include the EU/UK standard contractual clauses; they are written for U.S. state privacy laws.

Data export. A member who holds the Owner role can ask for a copy of the workspace’s data in Settings > Data export while the workspace is on trial, active, past due or read-only, and for 30 days after it closes (on our application address, app.activeq.app). We build a zip file in the background and email the owner who asked a signed link that works for 7 days; the link is a bearer link, so anyone who holds it can download the file until it expires. The export file, which holds the workspace’s personal data, contains tickets and their messages (including internal notes), the survey answers (score and comment) given for them, contacts, organizations, tags, members (name, email address, role and status), roles and part of the workspace’s configuration (for example statuses, macros, email templates, SLA policies and automation rules). It also contains the workspace’s knowledge base: the articles that are not deleted (Markdown text, status, audience, the user id of the author and the dates of the review steps), the categories and tags, which tags and client organizations each article is linked to, and the metadata of the images the articles use (type, size, dimensions, checksum, uploader and dates). Attachments and knowledge base images are not inside the file; each is listed with a download link, and the image links work for the same 7 days as the attachment links. It leaves out deleted records, the version history of knowledge base articles, edits waiting for review, helpful votes and view records, the timeline of events, sign-in records and sessions, API keys and webhook secrets, billing records, AI usage records and the audit log. It is limited to one export in 24 hours. Once the owner downloads the file, the customer is responsible for protecting it. We send the link by email through Resend, as for our other email.

API and webhooks. A workspace can create API keys and webhook endpoints. API responses and webhook messages carry workspace data (for example tickets, comments, contacts, organizations, tags, members and knowledge base articles; knowledge base webhook messages carry article details but not the article text) to the applications and endpoints the customer configures. We send it on the customer’s instruction, as its processor; we do not control those recipients, and the customer is responsible for them, for their security and for having the right to send the data there. Webhook messages do not include configuration, security or billing events, and internal notes are included only if the customer turns that on for an endpoint or, for app connections, in Settings > Integrations. For app connections (such as the Zapier app) we store the connection’s name, role, status and last use, who approved it, and SHA-256 hashes of its authorization codes and tokens (never the tokens themselves). For API keys we store a SHA-256 hash of each key (never the key itself), its name, role and expiry, the date and IP address of its last use, and up to 50 networks it was used from. For API usage we keep request and error counts per key and hour for 90 days. For webhooks we keep a delivery log for 30 days, with the message body, request headers without the signature, the response status and duration, and the first 1 KB of the receiver’s response. Idempotency records for API writes are kept for 24 hours. To check a webhook address before sending, we look up its hostname through Cloudflare’s public DNS resolver, so the hostname is shared with Cloudflare. These retention periods are fixed.

11. AI features

When they run. AI actions run only when a staff member with permission clicks a button on a ticket they can see: draft a reply, summarize a conversation, suggest a category, priority, sentiment or language, translate a message, polish text the staff member wrote, write an internal resolution note, or draft a help article from a resolved conversation. If a workspace owner has switched it on, a staff member can also have the web searched for a problem described in a ticket (“Research”, described below). They never run automatically and are not available to requesters on a portal. A person reviews the result before anything is sent or saved; sentiment is a suggestion shown to staff on the ticket and is not stored on the requester’s record. We do not train AI models on workspace content.

What is sent. To perform the action we send Anthropic, PBC (our AI provider) the ticket subject and the message text that the staff member clicking can read, which for actions such as a summary can include internal notes; internal notes are not included in drafts of public replies. For a draft we also send the requester’s first name (or a placeholder), the agent’s display name and the workspace name. For suggestions we send the names of the workspace’s categories and priorities. Polish sends only the text the staff member wrote and the workspace name, not the ticket. A resolution note uses the same context as a summary, so it can include internal notes. A help-article draft uses only the public messages of the conversation (never internal notes), and it also hides the requester’s and the staff member’s names whatever the workspace setting. The draft is saved as an article in the workspace’s knowledge base like any other draft. Saving, editing, reviewing, publishing and searching knowledge base articles do not involve the AI provider, and we do not send existing articles to it. We never send attachments, custom fields, contact or organization records, other tickets, or other workspaces’ data.

Web research. Research is off by default. Only a workspace owner can switch it on, in Settings > AI, and can switch it off again at any time; while it is off, nothing is searched. When it is on and a staff member clicks Research on a ticket, we send Anthropic, PBC only the ticket’s public messages (never internal notes). First we remove, on a best-effort basis, the names of the requester, of the staff member who clicked and of the workspace’s other staff members, and the workspace and organisation names, together with common personal identifiers; other names or details in a message may remain, so Research is not suitable for a ticket whose public messages you would not want an AI provider to see. Anthropic turns the messages into a few generic search queries. We filter those queries for personal details on a best-effort basis (email addresses, phone numbers, web and network addresses, file paths with user names, long numbers and long codes that look like account identifiers) before any search runs, and if nothing safe is left, nothing is searched and no credits are used. The searches are run by Anthropic and its search providers, who see only those queries, not the ticket. The results are third-party web pages. We store the answer, the search queries that the web search ran and the list of sources with the run and delete them after 30 days, like other AI output (section 4). Anthropic’s handling of what we send it is as described below.

Redaction. Before sending, we replace common personal identifiers in the text with placeholders such as “[email 1]”, and put them back only in the text shown to the staff member. This is pattern-based and best-effort, not a guarantee. It covers email addresses, phone numbers written with separators or a leading + (including variants with unusual space characters; a bare run of digits is not treated as a phone number), card numbers (checked with the Luhn test), US Social Security numbers, IBAN-like account numbers and long strings of letters and digits that look like keys or tokens. Owners can also choose to hide the requester’s name. It does not cover postal addresses, other people’s names, other national ID numbers, plain-text passwords or any other kind of information, so staff should not put such information into tickets they send to AI.

What Anthropic does with it. Anthropic acts as our sub-processor. We use its commercial API, and we have not agreed a zero-data-retention arrangement with it. According to Anthropic’s published Commercial Terms and privacy center pages as we read them on October 9, 2026, Anthropic does not train its models on commercial customer content by default, generally deletes API inputs and outputs from its systems within 30 days, and keeps content flagged for violating its usage policy for longer for trust and safety purposes. Those are Anthropic’s terms, not ours, and they can change; see how Anthropic stores data and its model-training statement.

What we keep. The AI output is deleted after 30 days (section 4). We keep the AI records described in section 1, a SHA-256 hash of the redacted input, the credit ledger and daily usage totals while the workspace exists. We do not store prompts, and we do not write ticket text or prompts to our application logs.

Your controls. Workspace owners can turn AI off for the whole workspace or per feature, switch web research on or off (it is off by default), set a monthly cap on AI credits (included runs do not count toward it), and hide requester names. We can also switch AI off for one workspace or for everyone. Each workspace has included runs for summaries, triage, translation, polish and resolution notes (fair use): 200 during the trial and 1,000 per month once paid; after that these actions use one credit each. Reply drafts (one credit) and help-article drafts (three credits) always use credits. Web research is free for the first 10 runs per workspace each calendar month, then it uses three credits. A new workspace gets 50 free credits in its trial. Failed, refused or cut-off runs are refunded automatically. AI output may be inaccurate. See section 12 of our Terms.

12. Changes and contact

We may update this policy by posting a new version here and changing the date above. Questions: support@activeq.app.