Early access
One inbox for every platform your customers talk on.
Looktra pulls conversations from separate messaging platforms into a single workspace, works out which messages belong to the same person, and keeps every thread in sync in real time.
Live today: workspaces, unified inbox, identity resolution and realtime delivery, running against a mock connector. Platform connectors are in development.
Message pipeline
processing
- 14:02:11.204connector.mockmessage.receivedchannel=mock
- 14:02:11.208identity-graphidentity.resolvedperson_8f2a1c
- 14:02:11.213messagingconversation.updatedthread_4471
- 14:02:11.219gatewayinbox.pushws://workspace/42
One message entering Looktra. Same four stages for every platform.
Design partners
Building alongside teams that live in five inboxes.
- Northwind
- Aperture
- Kestrel
- Halden
- Vireo
Placeholder marks. Replace with design partner logos before launch.
The problem
Your customers are one person. Your tools disagree.
A growing team ends up watching five or six places at once. Nothing is wrong with any single tool. The damage comes from the gaps between them.
01
Context is split across tabs
The same customer asks a question on one platform, follows up on another, and nobody sees the full story. Answers get repeated, or contradicted.
02
Nobody knows who is handling it
Without one queue there is no reliable sense of what is open, what is answered and what has been sitting untouched since yesterday.
03
Identity resets on every platform
One person can be a phone number, a username and an email address. Treating them as three people means three histories and three chances to get it wrong.
04
Automation stops at the tool boundary
Rules built inside a single platform cannot see anything that happened outside it, so the useful automation is exactly the automation you cannot build.
The approach
One workspace, built on an event pipeline instead of a mailbox.
Every incoming message enters the same pipeline no matter where it came from. What changes per platform is only the connector at the edge.
Normalise at the edge
Connectors translate each platform into one internal message shape. The rest of the system never learns platform-specific rules.
Running with the mock connector
Resolve who is talking
IdentityGraph links platform handles to one person record, so history follows the human rather than the channel.
Deliver without refresh
Messages persist, then push over WebSocket to open clients. The inbox updates as events land, not on a polling interval.
IdentityGraph
Three handles. One person. One history.
Identity resolution is the part most tools skip, and it is the reason unified inboxes usually feel like a folder rather than a workspace. IdentityGraph keeps a person record and attaches every platform handle to it as evidence arrives.
- One conversation history instead of one per platform.
- Merges are recorded, so a wrong link can be traced and undone.
- New platforms attach to the person that already exists.
Resolved record
person_8f2a1c
display_name = "Daniel K."
organisation = "Northwind"
linked_handles = 3
Unified inbox
Every platform lands in the same queue.
Threads carry their origin so context is never lost, but triage happens in one place with one set of habits.
Inbox / All platforms
connected
Daniel K.
2mAny update on the invoice from Tuesday?
Telegram
Northwind Ops
18mRe: onboarding checklist for the new workspace
Email
Mira Devlin
1hShared channel is live on our side, go ahead.
Slack
community
3hRate limit question from a self hosted setup
Discord
Maya C.
YesterdayThanks, that fixed it.
Telegram
Automation
Builder in progressRules that can see every platform at once.
The automation engine exists in the architecture and runs on the same event stream as the inbox. The visual builder is next, so the flow below is a design preview rather than a shipped screen.
trigger
Message received
any connector
condition
Identity resolved
known person
action
Assign to Support
round robin
action
Notify workspace
realtime
Design preview. The engine consumes the same events shown in the pipeline above.
Architecture
Event-driven, queue-backed, one path for every message.
The same four stages run for every message regardless of origin. Adding a platform means writing a connector, not touching the core.
Connector
Normalise the platform payload
Connector SDK
Ingestion queue
Buffer, retry, backpressure
Redis / BullMQ
Core services
Resolve identity, build conversation
NestJS / Prisma
Delivery
Persist, then push to open clients
PostgreSQL / WebSocket
Stack in production
Next.js
Web client
NestJS
API and gateway
PostgreSQL
Persistence
Prisma
Data access
Redis
Cache and queue backend
BullMQ
Job processing
WebSocket
Realtime delivery
Connector SDK
Platform integration
Security
Isolation first, because an inbox holds everything.
Communication data is among the most sensitive a company holds. The model is boring on purpose.
Workspace isolation
LiveEvery record is scoped to a workspace and access is checked at the query boundary, not only in the interface.
Secure authentication
LiveSession and token handling with hashed credentials, short-lived access tokens and explicit refresh.
Audit logs
In progressSecurity relevant actions are recorded so a workspace owner can answer who did what and when.
Passkeys
Coming soonPasswordless sign in with WebAuthn, planned once the connector work settles.
Roadmap
3 of 8 phases shippedWhat is done, what is being built, what comes after.
Published as it stands. Nothing on this page is marked complete unless you can use it today.
- Phase 01Live
Infrastructure
Monorepo, database, queue, deployment pipeline and local development setup.
- Phase 02Live
Authentication
Registration, sign in, sessions, workspace creation and membership.
- Phase 03Live
Identity and messaging foundation
Mock connector ingestion, message persistence, IdentityGraph resolution, conversation building, realtime inbox and notifications.
- Phase 04In progress
Connector SDK
A documented contract for building platform connectors, with the mock connector as the reference implementation.
- Phase 05Coming soon
Platform connectors
Telegram first, then Slack, Email and Discord.
- Phase 06Coming soon
Automation builder
Visual rules on top of the existing automation engine.
- Phase 07Coming soon
AI assistance
Summaries, drafts and routing suggestions, scoped per workspace.
- Phase 08Coming soon
Marketplace
Third party connectors published against the SDK.
FAQ
Technical questions, answered plainly.
Early access
Get a workspace while the connectors are being built.
Early access is limited on purpose. The people who join now shape which platform lands after Telegram and what the Connector SDK has to support.
No card. No launch date promised. You will hear from a person, not a sequence.
One inbox. Every platform. One identity. Automate everything.