QUASAR
Signal infrastructure for product events.
QUASAR receives events from websites, applications and backend services, turns them into readable messages and delivers them to Telegram through routing rules. The product sends one JSON payload; the infrastructure handles the rest.
One endpoint. Many signals.
Orders, leads, payments, errors and any other product events flow through one ingest contract. QUASAR separates the event itself from its destination and presentation.
Send an event and follow its route.
A compact version of the real workflow: choose an event, send it and see the resulting signal.
{
"event": "order.paid",
"project": "demo-project",
"data": {
"title": "Order #DEMO-1842 paid",
"route": "#sales-demo"
}
}Order #DEMO-1842 paid
amount: 18 900 RUB
customer: user@example.com
source: checkout
Not notification code. A delivery system.
Notification logic no longer lives inside every application. QUASAR becomes an independent layer that can evolve without changing event producers.
One ingest endpoint
Products send structured events to one API contract instead of owning notification logic in every service.
Routes and destinations
Rules decide which event goes to which Telegram channel, group or personal chat.
Reusable templates
Payload fields become consistent human-readable messages without hardcoding copy in product code.
Bot delivery
Telegram bots handle the last mile while QUASAR owns routing, retries and message preparation.
Signal analytics
Event volume, delivery state and operational visibility stay in one control surface.
Infrastructure-first deployment
Spring Boot, PostgreSQL, Redis and Docker keep the system simple to operate and extend.
A live interface, not a concept.
The case now uses patterns from the real Quasar product: dashboard, projects, push subscribers, template editing and project creation. Every value below is intentionally anonymized.
Overview
An anonymized production-style workspace.
Sent today
↗ demoPayloads received
↗ demoActive projects
↗ demoErrors today
↗ demoProject Alphaalpha.example
ActiveProject Betabeta.example
ActiveProject Gammagamma.example
Off{"event":"order.created","id":"DEMO-1042"}2m{"event":"lead.created","source":"landing"}8m{"event":"payment.succeeded","amount":4900}24mThe layer between product and Telegram.
QUASAR receives external HTTP traffic, persists configuration in PostgreSQL, uses Redis for fast runtime state and delivers final messages through the Telegram Bot API.
The stack running in production.
The case describes the real operational layer of QUASAR, not an abstract architecture diagram.
Integration starts with one POST.
No SDK is required: any service capable of making an HTTP request can use QUASAR.
curl -X POST \
https://quasar.ai-vai.com/api/v2/ingest \
-H 'Authorization: Bearer <token>' \
-H 'Content-Type: application/json' \
-d '{
"event": "order.paid",
"project": "demo-project",
"data": {
"orderId": "DEMO-1842",
"amount": 18900
}
}'An event should be emitted once.
The product reports what happened. QUASAR decides who needs to know, how the signal should look and where it should go. That is the system boundary.
OPEN QUASAR