Permissions at the serializer, not in the UI
Hiding a field in the interface is not enough: the server simply never sends it. That closes leaks through search, exports and the API at once.
The problem.
Deals, wallets and rates were scattered across personal chats. When a manager left, the history left with them. Payouts were checked by hand against a sheet with dozens of columns, and sensitive fields were visible to everyone who had the link.
What we built.
- Telegram chats inside the CRM, across many accounts: search, pins, edits, media, forwarding and handing a chat to a colleague.
- Two ways to connect an account. The official Business API is the default because it carries no ban risk; session login is a fallback, encrypted at rest.
- Field-level permissions with five levels, from hidden to export. A hidden field never shows up in a card, a list, search results or an export file.
- A 27-column payout reconciliation that reads the client’s Google Sheet by header names, so moving a column does not break it. Results are written back to the sheet.
- Rule-based alerts, for example when a new wallet address appears in a chat, plus a log of every critical change.
Decisions worth explaining.
One persistent client per account
Opening a chat went from several seconds to about 0.3 s once each account kept a live connection instead of reconnecting on every request.
In numbers.
620+live checks against a running server before handover
0.3 sto open a chat, down from several seconds
16screens, from chats to finance and analytics
19client revisions closed in one round
Stack
- FastAPI
- SQLAlchemy 2
- PostgreSQL
- React
- TypeScript
- Telegram Business API
- Telethon
- Google Sheets API
- nginx
- systemd
Need something like this?
Describe your process. We will tell you which parts of this system fit it and what it would cost.