Integrations
Two kinds:
- Federation — read-side. We pull session context from your existing observability stack for every feedback submission. The clarifying agent sees it; the ticket carries it.
- Tracker — write-side. On finalize, we file the structured report as an issue in your tracker. Two-way status + comment sync.
You bring your own keys. Earshot never owns the underlying data.
Federation providers
| Provider | Status | What we pull |
|---|---|---|
| PostHog | Real | Session replay URL, recent events for the affected user (±60s window), active feature flags |
| Sentry | Stubbed | Roadmap: recent errors for the affected URL |
| LogRocket | Stubbed | Roadmap: replay URL bracketing the moment of submission |
| Datadog | Stubbed | Roadmap: RUM sessions + APM traces for the affected route |
| Hotjar | Stubbed | Roadmap: recording link |
Stubbed providers connect + persist credentials but return empty federation entries until their real implementations land. Per the product vision, PostHog ships first as the reference; the rest follow without architectural changes.
Trackers
| Provider | Status | Capabilities |
|---|---|---|
| Linear | Real | Create issue with full context, status writeback (workflow state matched by type), comment mirror, resolution comment |
| Jira | Pending | Schema fields ready; provider impl in next sprint |
Setup
Three paths, same end state.
Via agent (recommended)
In your coding agent: "set up earshot integrations". The earshot-integrations skill scans your codebase for evidence of services in use, presents a ranked plan, and walks you through each. You confirm each sensitive credential by its last 4 chars before it ships.
Via the MCP
If you're an agent, call:
suggest_integrations(detected: DetectedService[])
We return a ranked plan with required_fields, setup_method, next_call (a fully-shaped connect_integration payload). Then for each:
connect_integration(provider, credentials, config, actor)
test_integration(provider)
See MCP for tool schemas.
Manual
The dashboard's project settings page surfaces install instructions per integration (coming soon — for now, run the MCP tools via curl).
Security model
Credentials are encrypted at rest with AES-256-GCM using INTEGRATION_ENCRYPTION_KEY (32 bytes, hex-encoded). Each row stores a {v, alg, iv, tag, ct} JSON envelope; nothing in the database surfaces the raw key.
The connect_integration response surfaces only the last 4 characters of each sensitive field (e.g. ••••abc7). Logs follow the same rule. list_integrations never returns credentials at all.
Decryption happens only at use-time, in-memory, on the dashboard and MCP servers. Both share the same key. Rotate by re-encrypting every row with the new key (script TODO).
In production we'll swap the app-secret-keyed AES path for Supabase Vault or AWS KMS without changing the on-disk envelope shape.
Audit log
Every connect / test / sync writes a row in integration_events (action, actor, message, timestamp). Surfaces on the dashboard's integration page.
What's deliberately not built
- No GitHub Issues, Asana, ClickUp, Monday, Trello, or Basecamp at launch. Each is a known good integration we'll add post-MVP; none belong in the first release.
- No webhooks-in (tracker → us) for status sync. Requires a public URL — lands once we deploy.