Исходящие уведомления сервисов (email, Telegram, web-push, system-to-system доставка) идут через хаб Gnexus Synapse. Каждый сервис, который шлёт уведомления, интегрируется с Synapse и не держит собственных каналов доставки. Как Synapse доставляет и кому — решает маршрутизация Synapse, не отправитель.
.env и gnexus-creds.syn_*, показывается ровно один раз: в .env сервиса и в gnexus-creds. Ключ — только удостоверение источника; имя source в конверте должно совпадать с источником ключа (анти-спуфинг).POST https://synapse.gnexus.space/api/v1/events, заголовок Authorization: Bearer syn_*. Приём мгновенно возвращает 202 — обработка асинхронная. Статус доставки — GET /api/v1/events/{id}.source, subject, action, priority (low|normal|high|critical), payload (объект), dedup_key, ttl_seconds, scheduled_at. Полный контракт — docs/05-ingestion-api.md в репо Synapse.payload.user_id = sub gnexus-auth (это часть payload-конвенции, не получатель).gn-synapse-client-py (PyPI gnexus-synapse), gn-synapse-client-php (Composer gnexus/synapse-client), установка по тегу v0.1.0. Конфиг только env:| env | что | |---|---| | SYNAPSE_URL | базовый URL хаба | | SYNAPSE_API_KEY | ключ syn_* источника | | SYNAPSE_TIMEOUT | таймаут HTTP, сек | | SYNAPSE_DEFAULT_SOURCE | умолчание source (смягчает 403 анти-спуфинга) |Сервис, который хочет получать события (Navi-инстансы и др.), отдаёт webhook-эндпоинт, и он регистрируется в Synapse как цель (Target). Дальше Synapse сам шлёт deliveries с ретраями; статусы видны в логе доставок админки.
docs/05-ingestion-api.md)10-systems/services/gnexus-synapse.md