Vue d'ensemble
Les fonctionnalités marketing et support d'Inklura sont fournies par une poignée d'applications outils PRISM (SMS Designer, Mail Designer, SEO, la console) qui reposent sur deux backends distincts. Savoir quel backend une fonctionnalité utilise vous indique comment l'appeler, où vivent ses données et — c'est important — ce qui est programmatique par rapport à ce qui est manuel ou encore à l'état de stub.
Deux mondes
Chaque intégration présentée sur cette page communique avec l'un de ces backends, ou les deux :
| Backend | Où | Ce que c'est | Usage typique |
|---|---|---|---|
| SDK loopback bext | http://127.0.0.1/__bext/sdk/* |
KV par application, queue et task-executor à chaud, joignables uniquement depuis des appelants sur l'hôte. | Le stockage et le travail d'arrière-plan propres à une application outil — enregistrements de campagnes SMS, jobs de rapports SEO. |
| tRPC company-manager | https://manage.inklura.fr/api/trpc/* |
L'API Plateforme canonique au-dessus de Neon Postgres. | CRUD/envoi de campagnes email, analytics de campagnes, journeys, helpdesk. |
Le SDK est uniquement accessible sur l'hôte — un site PRISM le joint via
loopback avec un en-tête X-Bext-App-Id, et les données de chaque application
sont cloisonnées à cet id. Voir les pages
Vue d'ensemble du SDK, KV, Queue et
Tasks. L'API tRPC est la surface publique documentée sous
API Plateforme ; ses conventions d'appel (enveloppes
superjson, result.data.json, authentification Bearer) s'appliquent à chaque
procédure tRPC nommée ici.
Les surfaces d'intégration
| Surface | Backend(s) | Point d'entrée principal |
|---|---|---|
| Campagnes SMS | SDK bext (KV) + passerelle Capitole Mobile | POST /api/campaigns (SMS Designer) |
| Email & MJML | tRPC company-manager + pont Mautic | routers campaigns / emailAnalytics |
| Journeys marketing | tRPC company-manager | router journeys |
| Rapports SEO | SDK bext (KV + tasks) + API de fournisseurs | POST /api/seo/reports (application SEO) |
| Helpdesk & KB | tRPC company-manager | router helpdeskKb + /manage/helpdesk |
Honnêteté : ce qui est programmatique, manuel ou à l'état de stub
Plusieurs de ces fonctionnalités sont partielles. Lisez ceci avant de développer dessus :
Le pourcentage de livraison SMS est saisi manuellement, pas récupéré. La passerelle Capitole n'a aucun callback d'accusé de réception (DLR) branché. Dans les rapports, « Délivrés » et « Lus » sont des estimations de référence (~95 %) à moins qu'un opérateur ne saisisse manuellement le chiffre depuis le portail Capitole. Les métriques de clic sont réelles. Voir Campagnes SMS.
Les étapes d'action des journeys sont pour la plupart des stubs v1. Dans un
journey, seule l'étape EMAIL envoie réellement quelque chose. SMS est un stub
non fonctionnel, et WEBHOOK, UPDATE_FIELD, ADD_TO_SEGMENT /
REMOVE_FROM_SEGMENT, CREATE_TASK et SEND_NOTIFICATION sont aujourd'hui des
no-ops qui ne font qu'avancer — une étape WEBHOOK n'émet pas de webhook
sortant. Voir Journeys marketing.
La planification SMS est déléguée, pas locale. Il n'y a ni cron ni queue local
pour les envois SMS ; une campagne planifiée est confiée au champ prog de
Capitole, et la passerelle la retient. La livraison email est déléguée à un pont
Mautic auto-hébergé. Les analytics email se dégradent proprement lorsque
le service d'analytics externe (QUEUE_MANAGER_URL) est injoignable.
Où aller ensuite
| Page | Ce qu'elle couvre |
|---|---|
| Campagnes SMS | La passerelle Capitole, l'API d'action /api/campaigns, le stockage KV, le flag d'honnêteté sur le % de livraison, les rapports publics |
| Email & MJML | Le compositeur MJML, le pont de livraison Mautic, le CRUD/envoi campaigns, emailAnalytics, le suivi des ouvertures/clics |
| Journeys marketing | Le router journeys, les déclencheurs, les types d'étapes (avec les flags de stubs v1), les templates et comment se déclenche l'enrôlement |
| Rapports SEO | Les fournisseurs de données, le pipeline de rapport asynchrone (POST /api/seo/reports + SSE) et le task-worker à chaud |
| Helpdesk & base de connaissances | Le router helpdeskKb, les tickets en tant que threads d'inbox, et la KB comme exemple de defineEntity |