Security and data
What data Airhop stores, where it lives, who processes it, and how to delete it.
Airhop handles your customers' data, so you should know exactly what we store, where it goes, and how to get rid of it. This page is the honest version: what is true today, without certification claims we have not earned yet.
What Airhop stores
You send Airhop data through four doors, and each stores something specific:
| Source | What is stored |
|---|---|
| Product events | The identify, track, page, and group calls you send: user ids, event names, the traits and properties you choose to include, and timestamps. |
| The widget | Contacts (id, email, name, custom attributes you pass) and conversations — every message between your customers, the agent, and your team, including escalations. |
| Knowledge sources | The pages we crawl, documents you upload, and content from connected sources (Slack channels, Gmail), chunked and embedded for retrieval. The crawler only fetches URLs you point it at. |
| Integrations | What each connector syncs: CRM fields from HubSpot (ARR, renewal date, owner, stage), call summaries and sentiment from Fireflies, and the OAuth credentials for each connection. |
Where it lives
All of it lives in a managed Postgres database in the US East region — events, contacts, conversations, and the knowledge index (embeddings included) are in the same database, not scattered across services. Traffic to and from Airhop is encrypted in transit with TLS. Connector credentials (OAuth tokens) are additionally encrypted at rest at the application layer, and a widget's identity secret is never returned by any API.
Tenant isolation
Every row in the database carries a workspace id, and every query runs inside that workspace's scope — enforced globally at the application layer, not per-query by convention. Route bindings resolve records within the current workspace only, so one workspace can never read another's contacts, conversations, or events, even by guessing ids.
Roles and permissions
Workspace members have one of two levels:
- Owner / admin can do everything, including the sensitive actions below.
- Member can do everything else — drafting outreach, reading every contact and conversation, running the day-to-day — but not the actions reserved for admins.
Owner or admin is required to:
- connect or disconnect integrations, and manage billing;
- delete accounts or knowledge, and erase a person's data (GDPR);
- publish FAQ answers to the help center;
- invite members;
- switch a playbook to auto-send.
Everything short of those is open to members, so most of your team can work without holding the keys to billing, integrations, or data deletion.
Widget identity verification
By default the widget trusts the identity your page passes it, which is fine for most sites but means a visitor who edits your page's JavaScript could claim another user's id. If that matters for your product, enable identity verification on the widget. With it on, Airhop only binds an identity when it carries a valid signature:
user_hash = HMAC-SHA256(user_id, your widget identity secret)Compute the hash on your server (the secret must never reach the browser) and pass it alongside the identify call:
window.Airhop('identify', {
user_id: 'user_123',
email: 'jo@acme.com',
user_hash: '<computed server-side>',
});An unsigned or invalid identity is not rejected loudly — the conversation simply proceeds as anonymous, so a forged id can never attach to a real customer's history. The same forgery concern is why server-side event ingestion distinguishes the public write key from the secret key.
Where the widget can load
The chat widget only runs on domains in your workspace's allow-list, set during onboarding or in Widget settings. An empty list is unrestricted — fine while you develop, but add your production domain before launch so the widget cannot be embedded on a site you do not control. Subdomains are separate origins, and a wildcard like *.example.com covers them at any depth. This is a browser-Origin check on the widget only; it does not affect server-side event ingestion, which is authenticated by key. Full details are in Install the widget.
Subprocessors
Airhop uses a small number of third-party services to operate, in plain terms:
- LLM provider — OpenAI, via API. Answering and embedding your knowledge uses the OpenAI API. Per OpenAI's API policy, data sent through the API is not used to train their models.
- Email delivery. A transactional email provider sends and receives the emails Airhop handles: handover notifications, customer replies, and playbook messages.
- Managed OAuth. Some connectors (HubSpot, Fireflies, Gmail) authenticate through a managed OAuth provider that brokers the connection; credentials are stored encrypted against your workspace.
- Hosting. The application and database run on managed cloud infrastructure in the US East region.
We do not sell your data, and no subprocessor receives more than it needs to perform its function.
Certifications
Airhop does not currently hold SOC 2, ISO 27001, or similar certifications. We would rather tell you that plainly than imply otherwise. If your security review needs specific answers, ask us directly.
GDPR and deletion
- Per-person erasure is built in. From the People page, deleting a contact removes their events, conversations (including every message and escalation), and milestone history in one transaction. Aggregate billing counts survive, but with no link to the person and no PII.
- Workspace deletion on request. Email us and we will delete your workspace and everything in it.
- Retention. Product events are pruned after 13 months. Everything else — contacts, conversations, knowledge — is retained for the life of your workspace unless you delete it.
Questions about security, data handling, or a DPA? Email support@airhop.ai — a person reads it.