asyncmate Privacy Policy
Effective date: September 13, 2026
asyncmate ("asyncmate", "we", "us", or "our") is an asynchronous standup, check-in, reminder, and poll bot for Slack and, in beta, Microsoft Teams. This Privacy Policy explains what personal data we collect and receive, why we process it, the legal bases we rely on, who we share it with, and the rights you have. It is written to be read alongside our Terms of Service, into which it is incorporated by reference.
We have written this policy in plain English.
1. Scope and who this policy covers
This policy applies to everyone whose personal data flows through asyncmate:
- Account owners / workspace admins: the people who sign up for an asyncmate account and connect a Slack workspace or a Microsoft Teams team.
- End users / workspace members: the people in a connected Slack workspace or Microsoft Teams team who receive prompts, answer check-ins, or vote in polls. Most of your data reaches us indirectly, through the workspace or team you belong to, rather than because you signed up with us directly.
- Website visitors: people who visit asyncmate.com.
Because some data reaches us indirectly (from Slack or Microsoft rather than from you), this notice is designed to satisfy both Article 13 (data collected from you) and Article 14 (data received from a third party) of the GDPR.
2. Who we are: controller and processor roles
asyncmate is operated by:
- Legal entity: Code7 d.o.o.
- Place of establishment / registration: Croatia
- Registered address: Zagorska ulica 105, 42220 Novi Marof, Croatia
- OIB (tax number): 76594489608
- Company registration number (MB): 06051537
- Court register: Trgovački sud u Varaždinu, MBS 070213717
- Contact: support@asyncmate.com
We are a small vendor established in the EU (Croatia). On that basis, Code7 d.o.o. has assessed that it is not required to appoint a Data Protection Officer, because our processing does not consist of large-scale systematic monitoring or large-scale processing of special-category data. On the same basis, being established in the EU, we are not required to appoint an Article 27 EU representative.
Our dual role under the GDPR. Which role we play depends on the data:
- For Customer Data (the standup and check-in answers, poll and survey votes, kudos messages, hours logged, out-of-office notes, and Slack or Teams messages directed at the bot), the connected Slack workspace or Microsoft Teams team (your organization) is the controller and asyncmate acts as a processor, handling that data on the workspace's documented instructions under our Data Processing Agreement (the "DPA"), which forms part of our Terms of Service.
- For account, billing, usage, security, and website data (the information tied to the person who signs up and pays), asyncmate is the controller.
This distinction determines who is responsible for answering a data subject request: for Customer Data we act on and assist the workspace controller; for account and billing data we are directly responsible.
3. Data we collect and receive
3.1 Account identity (you sign up)
- Email address (your login), and a securely hashed password (via ASP.NET Identity; we never store plaintext passwords).
- Email-confirmation flags and timestamps.
- If you sign in with Slack, Google or Microsoft instead of a password: the identity provider's stable subject identifier and your verified email, linked to your account. No password is stored for sign-in-with-Slack, sign-in-with-Google, sign-in-with-Microsoft, or magic-link accounts.
3.2 Session and authentication data
- Refresh tokens stored only as a SHA-256 hash: the raw token is handed to your browser once and never persisted by us.
- Short-lived JWT access and refresh tokens carried in secure, HttpOnly cookies, with rotation and replay/theft detection metadata (token family id, expiry, used/revoked flags).
3.3 Slack workspace and team metadata (received from Slack)
- Slack team ID (the tenant key), bot user ID, authorizing user ID, granted OAuth scopes, enterprise-install flag.
- The workspace's Slack bot access token, AES-256-GCM encrypted at rest and blanked when the app is uninstalled.
- Sync and install/uninstall timestamps.
3.3a Microsoft Teams team metadata (received from Microsoft, Teams beta)
- Teams team ID (the tenant key for that team), the Microsoft 365 tenant ID, and the Bot Framework service URL for the region the team lives in.
- Bot install time, and a hashed one-time claim code (with its expiry) that the team owner types into the dashboard to link the team to an account. The code itself is never stored.
- Conversation references: the conversation ID and service URL of each personal chat the bot has opened with a member, and of each channel it posts to, so that scheduled prompts and digests can be delivered without a user having to message the bot first.
- No per-tenant access token is stored. The bot authenticates to Microsoft with our own app credentials, held in server configuration outside the database.
A team that installs the bot but is never linked to an account is purged, with all of the member data below, after the same 14-day window described in §8.
3.4 Member profiles (received from Slack or Microsoft Teams)
- Slack user ID, display name / real name / first and last name, profile image URL.
- Timezone (IANA name, label, offset) and any member-set timezone override.
- Role flags (admin, owner, restricted, bot, app user), deleted flag, and an email-confirmed boolean.
- For Microsoft Teams members: the Microsoft Entra object ID (stored as the member's Teams user ID), display name, given name and surname, as returned by the Teams roster. Teams does not give us profile images, role flags or timezones; a member may set a timezone override themselves.
We do not store members' email addresses. We request Slack's
users:read.emailscope, and Slack returns the member's email address to us, but that address passes only through a transient in-memory object used to derive a single yes/noIsEmailConfirmedflag. We persist that flag only, never the address itself.
3.5 Channels (received from Slack or Microsoft Teams)
- Slack: channel ID and name, private/general/archived flags, and channel-to-member membership, so an admin can choose a digest channel and participants.
- Microsoft Teams: the ID and name of each standard channel in a connected team.
3.6 Check-in and survey response content: the core of the product
- Answers to standup / check-in questions, including free-text prose (for example "yesterday I…", blockers) and structured select / scale / yes-no answers, with a submission timestamp.
- For named runs, answers are keyed to the responder's Slack user ID. For anonymous runs, answers are keyed to a per-run one-way hash instead: the salt is discarded when the response window closes, so the hash cannot be reversed back to a person. One honest caveat: the text of an answer can still reveal who wrote it, especially in a small team. "Anonymous" means we store no technical link to the author, not that the content itself can never identify someone. A second caveat: while a run is open, its salt exists in our database, so an encrypted backup taken during that window (kept up to 30 days, see §8) contains it for that period. We use backups only to recover from data loss, and we never attribute anonymous answers.
3.7 Poll and survey votes; kudos
- Selected options and a vote timestamp. Named polls key to the Slack user ID; anonymous surveys use the same irreversible per-run hash described above.
- Kudos given with
/asyncmate kudos: the sender's and recipient's Slack user IDs, the free-text message, and a timestamp. A kudos is posted publicly in the Slack channel where it is given (that is the point of the feature) and recorded on the dashboard.
3.8 Derived and AI-generated content
- Blocker ledger: per-member aging blocker records (Slack or Microsoft Teams member ID, AI-normalized blocker text, open/resolved status, timestamps) generated as a side effect of the AI digest.
- Frozen AI digest snapshots: a stored copy of each generated digest, which may embed a member's display name and their blocker / action-item text, so we can show the digest in-app without re-calling the paid AI model.
These derived records persist while the workspace remains connected. They are member-linked and are therefore included in the erasure operation described in §9.
3.9 Hours-logger and out-of-office data
- Hours logged per project and date, hours-log settings and prompts, project-membership overrides, and out-of-office periods (start, end, and an optional note), keyed by Slack or Microsoft Teams member ID.
3.10 Billing and subscription data
- Per-workspace (keyed to the Slack team ID or the Microsoft Teams team ID): Stripe customer and subscription IDs, plan tier and status, billed seat quantity, current period end, cancel-at-period-end flag, whether and when the workspace used its one free trial, AI opt-out flag, and metering/usage counters.
- We never see or store card numbers. Payment details are entered directly on Stripe-hosted Checkout and the Stripe Customer Portal; we only receive back the Stripe customer and subscription identifiers.
3.11 Waitlist and feature-request submissions (public website)
- Waitlist: if you enter your email address in the "Keep me posted" form on our website, we store that address and the time you submitted it, so we can email you occasional news about asyncmate, such as a major feature shipping. Nothing else is stored with it: no name, no IP address, no tracking identifier, and it is not linked to any account or Slack workspace.
- Feature requests: the "what should we build next?" form on our website relays your message, and the reply address if you choose to give one, to our support inbox by email. It is not stored in our database; it stays in our support mailbox until we clear it (see §8).
3.12 Operational, log, and slash-command data
- Slack event records (event ID, team ID, type, time) used for webhook idempotency, OAuth attempt records, and run-participation rows. For Microsoft Teams, incoming bot activities are authenticated and de-duplicated at the job level; we do not keep a separate activity log.
- Payloads and identifiers we receive when the bot is used (including from
/asyncmateslash commands and interactivity actions), plus server logs and error diagnostics. We disclose this even though some of it is used only for operating and securing the service rather than as a product feature. - Your IP address is used, in memory only, to rate-limit sign-in, webhook, and public-form endpoints against abuse. We do not keep access logs, and IP addresses are not written to our database or sent to our error tracker.
3.13 Special categories of data
asyncmate is a workplace coordination tool and is not designed to collect special categories of personal data (health, religious or political beliefs, trade-union membership, sex life or orientation, biometric or genetic data). Workspaces must not configure check-in or survey questions that ask for such data (see our Terms of Service). Because check-ins accept free text, an answer may still incidentally contain sensitive information; such content is stored like any other answer, is never used for any secondary purpose, and is covered by the deletion and erasure mechanisms in §8 and §9.
4. Why we process your data, and our legal bases
Customer Data first. For Customer Data (check-in and survey answers, poll votes, kudos messages, hours, out-of-office entries, member profiles synced from Slack, and AI digest inputs) we act as a processor: we process it only to provide the service, on the documented instructions of the workspace that connected us, under our Data Processing Agreement. The workspace, as controller, is responsible for having its own legal basis under Article 6 GDPR for that processing and for informing its members about it; asyncmate does not determine that legal basis on the workspace's behalf. Workspaces must not use asyncmate for covert monitoring of workers, and should assess whether their configuration and local law call for a data protection impact assessment or employee-representative involvement before rolling it out.
For the processing where asyncmate itself is the controller, we rely on the following legal bases under Article 6 GDPR:
| Purpose | Data involved | Legal basis (Art. 6 GDPR) |
|---|---|---|
| Authenticate account owners, confirm email, run passwordless recovery, link OIDC identities | Account identity, session tokens | Contract (Art. 6(1)(b)) where you are the Customer; where you administer an account for your employer or another organization, legitimate interests (Art. 6(1)(f)) in providing the service that organization has contracted for |
| Meter active participants, run subscriptions, and take payment | Billing / subscription data | Contract (Art. 6(1)(b)) |
| Comply with tax, accounting, and other legal obligations | Billing records | Legal obligation (Art. 6(1)(c)) |
| Secure the service, prevent abuse and fraud, ensure webhook integrity, keep the scheduler reliable | Logs, event records, session and OAuth data | Legitimate interests (Art. 6(1)(f)): keeping our service secure, reliable, and free from abuse |
| Diagnose errors and improve the service | Error reports (see Sentry below), aggregate usage | Legitimate interests (Art. 6(1)(f)): running and improving our product |
| Send service emails about your account and subscription: welcome, email confirmation, sign-in links, over-limit notices, the trial-ending reminder, failed-payment and cancellation notices, and a one-time notice when the app is removed from your workspace explaining what happens to its data | Account owner email and workspace name; the trial-ending reminder also carries the titles of the workspace's open blockers | Contract (Art. 6(1)(b)) |
| Email you occasional product news, if you joined the waitlist | Waitlist email address | Consent (Art. 6(1)(a)) |
| Read and act on a feature request you sent us | Your message and the reply address you chose to give | Consent (Art. 6(1)(a)) |
Where we rely on legitimate interests, we have weighed those interests against your rights and freedoms. You can object at any time (see §9).
We do not run marketing campaigns, build mailing lists from our users, or set marketing cookies. The only non-transactional email we send is an occasional note about asyncmate news, such as a major feature shipping, and it goes only to people who asked for it by submitting the waitlist form. Submitting that form is your consent. We use the address only to send those updates and nothing else, and you can withdraw it at any time by emailing support@asyncmate.com or using the unsubscribe link in that email. If we ever start sending anything broader than that, we will ask for your consent (Art. 6(1)(a)) separately and give you an easy way to withdraw it.
5. AI processing (Anthropic / Claude)
The AI digest is an optional, paid (Pro-tier) feature that summarizes a check-in run into blockers and action items. To generate it, we send the following to Anthropic's Claude API:
- The free-text answers to the check-in, the question text, and the text of any prior open blockers.
We apply meaningful data minimization:
- Profile names are replaced with identifiers. Before sending, we swap each participant's profile name for their opaque Slack or Microsoft Teams identifier, and we resolve the names back on our own servers after the model responds. The answer text itself is sent as written, so it may still contain names or other personal information that participants typed. This reduces direct identification; it does not make the input anonymous.
- Only free-text (long-text / short-text) answers are used as the quote source.
- The default model is Anthropic's Claude Haiku, configurable by us.
We do not use Customer Data to train any AI or large language model, and we do not permit our AI sub-processor to train its models on it. As of the effective date of this policy, Anthropic's commercial API does not train on inputs by default, and Anthropic's published retention policy deletes API inputs and outputs within 30 days unless they are flagged for a usage-policy violation or law requires longer. We use the standard commercial API without a zero-data-retention arrangement. These points reflect Anthropic's commercial terms as they stand on the effective date and may change; the current terms are published by Anthropic at anthropic.com/legal. Our processing of Customer Data through Anthropic is governed by a data processing agreement with Anthropic as our sub-processor.
Per-workspace opt-out. Each workspace can turn the AI digest off. When AI is opted out, no check-in content is sent to Anthropic, and the digest degrades to a plain, non-AI summary compiled entirely on our own infrastructure.
AI output is labeled. A digest produced with AI carries an "AI summary" label in the digest, so readers can tell it apart from the plain digest compiled without AI.
AI output can be wrong. AI digests are automatically generated summaries and can be inaccurate or incomplete. They exist to help a team coordinate, and under our Terms of Service a workspace must not use them as the sole basis for decisions that produce legal or similarly significant effects on a person (see also §9 on Article 22 GDPR).
6. How we share data: sub-processors and other recipients
Sub-processors are providers that process personal data on our behalf. We enter into a data processing agreement with each of them before they process anything for us, and we use a deliberately small set:
| Sub-processor | Purpose | Data shared / received | Region |
|---|---|---|---|
| Hetzner Online GmbH | Cloud hosting and database (see §12) | All data at rest, hosted on our behalf | EU (Germany) |
| Anthropic (Claude API) | AI digest generation (see §5), only where the workspace has AI enabled | Check-in free-text answers (as written, so they may contain names participants typed), question text, and open-blocker text, with profile names replaced by opaque Slack or Teams identifiers (see §5) | US (see §7 for transfer safeguards) |
| Brevo (Sendinblue SAS) | Transactional email (SMTP) | Account owner email address and email body: confirmation and welcome emails, magic-link sign-in links, over-limit notices, trial, payment and cancellation notices, and the one-time notice sent when the app is removed. The trial-ending reminder can include the titles of the workspace's open blockers, drawn from check-in answers, without naming who wrote them. No other Slack or Teams member content is emailed | EU (France) |
| Sentry (Functional Software, Inc.) | Error monitoring (backend and frontend) | Unhandled exceptions with request context (URL, method, correlation ID). Personal-data mode is off, cookies and request bodies are excluded, and single-use auth tokens are scrubbed from captured URLs. Standup content is not sent | EU data residency (Germany), operated by a US company (see §7) |
| Microsoft (Azure Bot Service) | Message transport for the Microsoft Teams beta: every prompt, card, and reply between the bot and a Teams team passes through the Azure Bot Service resource we operate in our own Azure subscription | Teams member IDs and names, check-in answers, votes, hours and kudos submitted through cards, and conversation references | Microsoft routes bot traffic through its regional Bot Framework service for the team's Microsoft 365 region; covered by the Microsoft Products and Services Data Protection Addendum (see §7) |
| Cloudflare, Inc. (Web Analytics) | Cookieless page-view statistics for asyncmate.com (see §11) | Page URL, referrer, browser and device type, and a country derived from the connection; no cookies, no identifiers, and no standup content | US company, DPF-certified (see §7) |
| Cloudflare, Inc. (R2 object storage) | Off-site storage of database backups (see §8 and §12) | Encrypted database dumps. Backups are encrypted on our server before upload with a key that never leaves our infrastructure, so Cloudflare holds ciphertext only | EU-jurisdiction bucket; Cloudflare is DPF-certified (see §7) |
We will update this table before adding or replacing a sub-processor that processes Customer Data, and give account owners at least 30 days' advance notice as described in the DPA.
Platforms and independent services. Three further providers touch personal data, but for most of what they do they act as independent controllers (or as the platform you already use) under their own terms and privacy policies, not as our sub-processors:
| Service | Role | Data involved |
|---|---|---|
| Slack (Salesforce) | The platform asyncmate runs on: OAuth install, Web API (post messages, list users/channels, open DMs), Events and Interactivity webhooks. Your workspace's own agreement with Slack governs Slack's processing | We send bot messages, DMs, and digests into Slack; we receive workspace/team metadata, member profiles, channels, and interactivity payloads (check-in answers, votes). Via the users:read.email scope Slack also returns member email addresses, which we use only transiently to derive the IsEmailConfirmed flag and never store (see §3.4) |
| Microsoft (Microsoft Teams / Microsoft 365) | The platform the Teams beta runs on: the Teams client and your organization's Microsoft 365 tenant, through which the bot receives messages and card actions and sends prompts, digests and cards. Your organization's own agreement with Microsoft governs Microsoft's processing there. The Azure Bot Service we operate to carry that traffic is a separate service that acts as our sub-processor (see the table above). Also the optional "Continue with Microsoft" sign-in for the account owner (OIDC, work or school accounts), used only if the owner chooses it; Microsoft operates its identity service as an independent controller | We send bot messages and cards into Teams; we receive team and tenant metadata, member roster entries (Entra object ID and names), channel lists, and card submissions (check-in answers, votes, hours, kudos). For the optional sign-in: OAuth code exchange; we read the ID token's subject, verified email, and name |
| Stripe | Subscription billing: hosted Checkout, Customer Portal, webhooks. Stripe processes some subscription data on our behalf and acts as an independent controller for payment processing, fraud prevention, and its own legal compliance | Account owner email and Slack workspace ID as customer metadata; we receive back customer/subscription IDs. Card data is entered on Stripe's hosted pages and never touches our servers |
| Optional "Sign in with Google" for the account owner, used only if the owner chooses it. Google operates its identity service as an independent controller | OAuth code exchange; we read the ID token's subject, verified email, and name | |
| Notion Labs, Inc. | Optional integration the workspace owner connects. When enabled per check-in, we create one page per closed check-in run in a database we create in the workspace's own Notion, containing the same content as the digest (respondent display names, answers, the AI summary where enabled, and who didn't respond). Notion processes it under the workspace's own agreement with Notion, as the destination the workspace chose and controls | We send the digest content described in the previous column; we receive the Notion workspace id and name, the ids of the pages the owner shared, and the ids of the database and pages we create. We store an access token for the connection, encrypted at rest |
We do not sell, rent, or trade your personal data. We do not use Slack data for advertising, ad targeting, or to build advertising profiles, and we do not use Slack data to train large language models. We may disclose data if legally required (for example, a valid court order), or in connection with a business transfer, in which case we will give notice where the law requires it.
7. International data transfers
Our hosting is in the EU (Hetzner, Germany), so Customer Data is stored within the European Economic Area.
Some providers process data outside the EEA: Anthropic, Stripe and Cloudflare (United States), and Slack, Microsoft and Google (global). For each of those transfers we rely on a documented GDPR mechanism: the EU-US Data Privacy Framework, where the provider is certified under it as of the effective date of this policy (Stripe, Slack/Salesforce, Microsoft, Google, Cloudflare, and Sentry's US operator all are), and otherwise the European Commission's 2021 Standard Contractual Clauses as incorporated in that provider's data processing agreement (Anthropic's transfers rely on those Clauses). You can ask us at support@asyncmate.com for a copy of the relevant safeguards, with commercial details removed.
8. How long we keep data
We keep personal data only as long as needed for the purpose it was collected for.
Customer Data (member profiles, check-in responses, votes, kudos, blockers, hours, OOO) is retained while the Slack workspace or Microsoft Teams team remains connected.
The 90-day history window shown to free-tier workspaces limits what the dashboard and exports display; it is not deletion. Customer Data is deleted only through the in-app erasure tooling (§9), the post-uninstall purge below, or on the workspace's request.
On uninstall, we mark the workspace as uninstalled and stamp the time rather than deleting immediately. If the workspace is reconnected, that mark is cleared and nothing is purged, so a reinstall doesn't lose data.
A daily job hard-erases an uninstalled workspace's personal data 14 calendar days after uninstall. Deleting the workspace record cascades to its members, channels, routines and their runs, responses and participants, blockers, poll votes, hours entries and settings, project overrides, and Slack events; out-of-office periods and kudos are deleted explicitly.
What we deliberately keep after a purge is a small entitlement record keyed to the Slack team ID or Teams team ID (subscription/entitlement, usage counters, seat-sync proposals, processed-payment-event ledger). It contains no data about workspace members. It does hold the workspace's platform ID and the Stripe customer and subscription identifiers, which are pseudonymous billing references that can be linked to the account owner through Stripe; we keep them under our legitimate interest in preventing free-tier resets and keeping billing records consistent, for as long as the workspace could reconnect, and we delete them on request once no accounting obligation applies to them.
Account and billing records: invoices and the accounting records behind them are kept for 11 years, as required by the Croatian Accounting Act (Zakon o računovodstvu), then deleted. Account data that is not needed for those statutory records is deleted when your account is deleted.
Session tokens and event-idempotency records are short-lived and cleared once expired or used.
Backups: encrypted database backups are kept for no more than 30 days and then deleted by the storage lifecycle policy, so a member erased under §9 also disappears from backup copies within 30 days.
Error reports in Sentry are retained for 90 days.
Waitlist addresses are deleted by the same daily job 365 days after you submit them, whether or not we have launched by then, and you can ask us to remove yours sooner at any time (email support@asyncmate.com). Feature-request messages are not stored in our database; they stay in our support mailbox, which we clear out periodically.
Content sent to services you connect (for example Notion) stays there under that service's rules; disconnecting the service or deleting data in asyncmate does not delete it there.
Anthropic's retention of AI inputs (up to 30 days on the effective date, see §5) is governed by Anthropic's own terms.
9. Your rights
Under the GDPR you have the right to:
- Access the personal data we hold about you (Art. 15).
- Rectify inaccurate or incomplete data (Art. 16).
- Erasure: "the right to be forgotten" (Art. 17).
- Restrict processing (Art. 18).
- Data portability: receive your data in a portable format (Art. 20).
- Object to processing based on legitimate interests (Art. 21).
- Rights regarding automated decision-making (Art. 22). asyncmate does not make decisions producing legal or similarly significant effects solely by automated means. The AI digest summarizes text; it does not evaluate or make decisions about individuals.
- Withdraw consent at any time, where we rely on consent.
How we handle Customer Data requests. For data collected through a connected Slack workspace, the workspace (your employer/organization) is the controller. We have built tools that let a workspace's authorized account owner act on such requests directly:
- Access / export: retrieve everything stored about a given member: profile (including, for Teams, the stored Teams user ID), check-in responses, blockers, hours entries, OOO periods, poll votes, kudos they gave or received (direction, text, and date; the other person's identity is excluded as third-party data), and counts of related records.
- Erasure: atomically delete all of a member's linked records (including their check-in responses, blocker-ledger rows, hours entries, OOO periods, poll votes, and every kudos where they are the sender or the recipient), remove their name and text from stored AI digest snapshots, delete their Teams conversation reference where one exists, and scrub their Slack or Teams ID from check-in rosters.
Two categories sit outside that in-app tooling. Anonymous responses and votes are stored against an irreversible per-run hash, so we cannot attribute them to a person from anything we store (though the text of an answer may still reveal its author to people who know the context; see §3.6). Waitlist addresses (§3.11) belong to people who have no account and no workspace, so there is no in-app screen that could find them. Email support@asyncmate.com and we will delete yours, and in any case the daily job removes it after 365 days.
If you are a Slack or Microsoft Teams member, please raise access or erasure requests with your workspace administrator, who can action them in-app. You may also contact us and we will assist and forward the request to the relevant workspace.
Account owners. We do not yet offer a self-service "download my account" or "delete my account" button. To exercise any of your rights, including account access, correction, or deletion, email support@asyncmate.com.
How and when we respond. Requests are free of charge. We respond without undue delay and at the latest within one month. For a complex request, or if we receive many at once, we may extend by up to two further months; if so, we will tell you within the first month and explain why. We may ask for information reasonably needed to confirm you are the person the data is about before acting on a request.
Complaints. If you believe we have handled your data unlawfully, you have the right to lodge a complaint with your local supervisory authority. Ours is the Croatian Personal Data Protection Agency (AZOP, Agencija za zaštitu osobnih podataka), azop.hr. We would appreciate the chance to address your concern first.
10. Security
We protect your data with technical and organizational measures, including:
- Encryption of Slack bot tokens at rest using AES-256-GCM authenticated encryption, with a fresh random nonce per operation; tampering causes decryption to fail, and tokens are blanked on uninstall. The Microsoft Teams bot holds no per-team tokens: it authenticates with one application credential kept in server configuration, outside the database.
- Hashed credentials: passwords are hashed by ASP.NET Identity and never stored in plaintext; refresh tokens are stored only as SHA-256 hashes, with family-based rotation and replay/theft revocation.
- Enforced multi-tenant isolation at the data-access layer, not by convention: every tenant-scoped query is automatically filtered to the authorized workspace (no valid tenant returns zero rows), and writes take the workspace from the authenticated tenant, not from client input.
- Encryption in transit: HTTPS/TLS everywhere via automatic certificate management.
- Secure cookies: auth cookies are HttpOnly, Secure (enforced in production), and SameSite=Lax.
- Rate limiting on authentication endpoints, validated Slack webhook signatures, Microsoft-issued signed tokens verified on every Teams request, and an access-controlled operations dashboard.
- Minimized error telemetry: our error tracker excludes cookies and request bodies and scrubs single-use tokens; standup content is not sent.
No method of transmission or storage is ever 100% secure, and we cannot guarantee absolute security. We do not claim SOC 2 or ISO 27001 certification; we describe the actual controls we operate rather than certifications we do not hold.
11. Cookies and tracking
asyncmate uses only the cookies it needs to work: there are no advertising, analytics, or third-party tracking cookies. Specifically:
accessTokenandrefreshToken: the two essential authentication cookies, both HttpOnly, Secure (in production), and SameSite=Lax.- A short-lived
oauth_state_*cookie that protects the sign-in flow against cross-site request forgery during the identity-provider round-trip.
We also keep a few entries in your browser's local storage, all strictly functional:
theme: your light/dark preference.activeWorkspace: which workspace you last had open.postLoginRedirect(session storage): briefly remembers the page you were heading to during sign-in; cleared right after.waitlist-joined: remembers that you already joined the launch waitlist, so the form on our website stops asking. It stores no address, only the fact that you joined.
Because these cookies and storage entries are strictly necessary to provide the service, they do not require consent, and we show no cookie banner. If we ever want to set an optional cookie, we will first update this policy to name the exact tool and ask for your consent before it is set, because EU ePrivacy rules require consent to be specific and informed. If you answered our earlier cookie banner, that choice may still sit in your browser's local storage under cookieConsent; nothing reads it any more and you can clear it like any site data.
Cookieless site analytics. asyncmate.com, including the app, loads Cloudflare Web Analytics, a script that reports page views to Cloudflare so we can see how many people visit and which pages they read. It sets no cookies, stores nothing in your browser, and does not fingerprint you or follow you across sites; Cloudflare processes the connection's IP address only to derive a country and does not use the data for its own purposes. Because it uses no cookies or similar identifiers, it needs no consent and does not change the statement above; our legal basis is our legitimate interest (Art. 6(1)(f)) in understanding how the website is used.
12. Hosting
asyncmate runs on a single EU-based server (Hetzner, Falkenstein, Germany) with a self-hosted PostgreSQL database and automatic HTTPS. DNS for asyncmate.com is served by Cloudflare in DNS-only mode: site traffic goes directly to our server and does not pass through Cloudflare. Daily database backups are encrypted on our server and stored off-site in an EU-jurisdiction Cloudflare R2 bucket (see §6) for no more than 30 days. This setup keeps Customer Data within the EEA except for the specific transfers described in §6 and §7.
13. Children
asyncmate is a workplace tool and is not directed to children. We do not knowingly collect personal data from anyone under 16 (the GDPR digital-consent age; some EU Member States set a lower age between 13 and 16). If you believe a child has provided us data, contact us and we will delete it.
14. Changes to this policy
We may update this policy from time to time, for example when the service, our providers, or the law change. When we make a material change, we will update the effective date above and notify account owners by email or in-app before the change takes effect. This policy is a notice about how we process data, not a contract: if a new purpose ever requires your consent, we will ask for it separately before that processing starts, rather than treating continued use as agreement.
15. Contact
Questions, requests, or complaints about this policy or your data:
- Email: support@asyncmate.com
- Operator: Code7 d.o.o., Zagorska ulica 105, 42220 Novi Marof, Croatia (OIB 76594489608, MB 06051537)
- Court register: Trgovački sud u Varaždinu, MBS 070213717
- Place of establishment / registration: Croatia
- Governing law: Croatia
- Supervisory authority: AZOP (Agencija za zaštitu osobnih podataka, Croatia), azop.hr