- Qu'est-ce qui est considéré comme un abonné actif ?
- Toute personne ayant reçu ou lu une notification au cours de la période de facturation. Un utilisateur qui n'a rien reçu et n'a pas ouvert la cloche n'est pas comptabilisé, et un utilisateur désabonné l'année dernière ne l'est plus jamais.
- Le nombre de notifications est-il limité ?
- Non. Que vous envoyiez mille notifications à une personne ou une notification à mille personnes, le tarif reste le même. Facturer à la notification vous pousserait à rationner la fonction même d'existence du produit.
- Comment le module intégré s'authentifie-t-il ?
- Votre backend génère un jeton à durée de vie limitée désignant un utilisateur, signé avec votre clé d'application. Le composant intégré le présente et ne peut lire que la boîte de réception de cette personne et rien d'autre — il ne peut pas publier ni voir un autre utilisateur. Votre clé d'application n'atteint jamais le navigateur.
- Que se passe-t-il si le paiement par carte échoue ?
- La publication s'arrête. Vos utilisateurs continuent de voir les notifications déjà reçues, car supprimer leur boîte de réception reviendrait à les pénaliser pour un différend entre vous et nous.
- La livraison est-elle réellement en temps réel ?
- Oui, via Server-Sent Events, et la boîte de réception est stockée dans PostgreSQL plutôt que rejouée depuis un canal — ainsi, un utilisateur hors ligne retrouve l'ensemble de ses messages dans l'ordre à son retour. Rien n'est perdu en cas d'interruption du flux.
- Cela fonctionne-t-il sans framework JavaScript ?
- Il s'agit d'un custom element. Il fonctionne avec React, Vue, Svelte, Rails, Django ou sur une simple page HTML, et ne pèse que 2,7 Ko compressé en gzip, sans aucune dépendance.