Chaque boîte de dialogue « Nouveau … », expliquée en langage clair

Le nom de votre entreprise ou de votre équipe. Une simple étiquette — modifiable plus tard.

Où iraient les factures et avis de facturation de votre compte MeterFlow. Facultatif ; le format est validé, mais rien n’est envoyé pour le vérifier.

À quelle organisation appartient le projet. Présélectionnée si vous en avez déjà une active.

Le nom du produit, p. ex. « PixelForge AI ». Affiché partout dans le tableau de bord et dans le sélecteur de projet.

Texte libre, pour votre propre référence.

Une étiquette pour vous rappeler où la clé est utilisée — « Backend de production », « Staging », « Tests CI ». Aucun effet technique.

Les clés Live commencent par mf_live_, les clés Test par mf_test_ — et elles accèdent à deux jeux de données totalement séparés au sein du même projet. Les abonnements, crédits et usages créés avec une clé Test sont invisibles pour les clés Live (et inversement), tandis que vos meters et plans sont partagés : vos tests s’exécutent donc toujours contre votre vraie configuration de facturation. Utilisez des clés Test pour le développement, le staging et la CI ; les clés Live uniquement pour le vrai trafic de production.

L’étiquette lisible affichée dans le tableau de bord — « Images générées », « Secondes de rendu vidéo ». Pour les yeux humains uniquement.

La clé machine — et oui, elle est stockée dans la base de données et comparée à l’exactitude près. Quand votre application signale un usage, elle envoie un nom d’événement ; MeterFlow cherche dans ce projet le meter actif dont l’event_name correspond exactement, casse comprise. S’il n’en existe aucun, l’événement est rejeté avec une erreur 404 (« No active meter found for event … ») et rien n’est enregistré. Chaque nom d’événement est unique au sein d’un projet. Convention : minuscules avec des points, p. ex. image.generated.

Comment de nombreux événements individuels sont combinés en un seul nombre dans les récapitulatifs d’usage. Voir le tableau ci-dessous — c’est le cœur du meter.

Obligatoire pour Sum, Max, Min et Unique count ; refusé sur Count, qui ne lit aucune propriété. Il nomme une propriété de vos événements. Pour Sum, Max et Min, c’est là que la quantité est lue quand votre app omet value — un meter dont le champ est seconds lit properties.seconds ; un value envoyé par votre app l’emporte toujours, et un événement sans l’un ni l’autre compte pour 1. Pour Unique count, c’est la propriété dont on compte les valeurs distinctes — model, pour compter les modèles utilisés par un client.

Texte libre pour votre équipe.

Le nom du palier — « Free », « Pro », « Enterprise ». Obligatoire ; le bouton de création reste désactivé tant qu’il n’est pas rempli.

Texte libre, p. ex. la phrase d’accroche marketing du palier.

L’abonnement récurrent : Price est le montant (0 convient très bien à un palier gratuit), Currency un code comme USD, et Billing period la fréquence — mensuel, annuel, hebdomadaire ou paiement unique. Figés après la création — modifier le plan ensuite ne peut pas les changer (créez plutôt un nouveau plan, pour que les conditions des abonnés existants ne changent pas en douce).

Jours gratuits au début de chaque nouvel abonnement. Avec 14, un nouvel abonné passe 2 semaines au statut « trialing » avant le début de la période payante. 0 = pas d’essai.

Si le plan existe pour vos clients. Laissé désactivé, c’est un brouillon : vous pouvez en définir le prix, les limites et les clés de fonctionnalité en plusieurs fois, et vos clés d’API ne le voient jamais — il est absent de la liste des plans du SDK, un identifiant divulgué répond 404, et personne ne peut y être abonné. Les nouveaux plans sont publiés ; désactivez-le pour en préparer un tranquillement, puis réactivez-le à la mise en vente. Le désactiver ensuite ferme la porte aux nouveaux abonnés sans toucher à ceux déjà en place.

Les avantages oui/non inclus dans le plan — des clés courtes que vous inventez, comme sso ou priority-support (minuscules, chiffres, - et _). Votre app demande au SDK entitlements.check(customerId, 'sso') et obtient oui uniquement pour les clients abonnés à un plan qui liste cette clé. Modifiables à tout moment, sur les plans nouveaux comme existants ; pour ce que vous comptez, utilisez plutôt une limite de meter ci-dessous.

À quelle grandeur mesurée cette limite s’applique. La liste déroulante affiche les meters que vous avez créés dans ce projet — ni plus, ni moins. Ce n’est pas un catalogue figé : toute nouvelle capacité du produit demande simplement un nouveau meter d’abord, et il apparaît ici aussitôt.

Le volume compris dans le prix du plan, par période de facturation. « Pro inclut 500 images par mois » → 500. Sur une ligne Hard ou Soft, un chiffre est obligatoire avant de créer le plan — un volume vide ne plafonnerait rien — sauf si vous cochez Unlimited ci-dessous pour dire que c’était bien l’intention. Sur une ligne Metered, le vide est déjà une réponse : paiement à l’usage dès la première unité.

Uniquement sur les lignes Hard et Soft, et la façon explicite de dire « aucun plafond sur ce meter ». Coché, Included units est désactivé et vidé ; décoché, ce chiffre reste obligatoire. Les lignes Metered n’ont pas l’interrupteur, car le vide y signifie déjà quelque chose.

Le prix en crédits par unité une fois que le client dépasse les unités incluses — 0.5 signifie que chaque unité supplémentaire coûte un demi-crédit sur son solde. Il appartient au seul type Metered : le formulaire le demande sur une ligne Metered et le masque sur Hard et Soft, et l’API refuse un tarif sur une ligne Hard ou Soft (422). Une ligne Metered sans unités incluses ni tarif refuserait chaque unité, donc l’API refuse aussi cette ligne (422).

Ce que répond entitlements.check() du SDK une fois les unités incluses épuisées — l’appel que votre app fait avant d’effectuer le travail. Hard (bloquer) — check() répond non (hard_limit_reached) et votre app refuse l’action ; le client se heurte à un mur jusqu’à la période suivante ou une montée en gamme. Soft (avertir) — check() répond toujours oui, signalé soft_limit_exceeded : votre app laisse passer et incite le client à monter en gamme. Metered (facturer) — check() répond oui tant que les crédits du client couvrent les unités supplémentaires, et chaque unité supplémentaire est prélevée sur son solde au tarif de dépassement ; quand le solde ne suffit plus, la réponse est non (insufficient_credits). Metered est l’option « paiement à l’usage » et la seule qui déplace de l’argent (des crédits) toute seule. Une limite Metered est refusée sur un meter Max ou Min (422) : une valeur maximale ou minimale ne se facture pas à l’unité. Sur une ligne Metered, un plafond de dépenses sur l’abonnement du client peut faire répondre non à check() avant que le solde ne s’épuise (spend_cap_reached). Hard et Soft déclenchent le webhook limit.reached une fois par période de facturation, la première fois que la ligne est franchie. Dans tous les cas MeterFlow continue d’enregistrer les événements que votre app envoie — la barrière, c’est check(), dans votre code.

Votre propre identifiant du client final — n’importe quelle chaîne de votre choix : un ID utilisateur de votre base (user-842), un e-mail, un slug de tenant. MeterFlow ne le valide contre rien ; ce que vous envoyez désigne le propriétaire de l’abonnement. Utilisez le même ID partout (abonnements, crédits, usage), sinon les pièces ne se relieront pas.

Sur quel palier tarifaire il se trouve — la liste affiche les plans de ce projet. Si le plan a des jours d’essai, l’abonnement démarre en « trialing » ; sinon en « active ».

Son solde et chaque ligne de registre derrière, avec Grant et Deduct — les fenêtres expliquées plus bas.

Ce qu’il a utilisé, meter par meter.

Sa formule et son statut, avec Cancel ou Reactivate.

Ce que sa formule accorde, fonctionnalité par fonctionnalité : ce qui reste de chaque allocation facturée, et la raison pour laquelle une fonctionnalité est refusée, exactement comme entitlements.check() la donnerait.

Combien de crédits ajouter (Grant) ou retirer (Deduct). Doit être supérieur à zéro — la direction est décidée par le bouton qui a ouvert la boîte de dialogue, pas par un signe moins.

Une note facultative enregistrée sur la ligne du registre — « Bonus de bienvenue », « Remboursement suite à l’incident », « Geste commercial ». Votre futur vous dira merci.

Il dure 60 minutes, sauf si vous fixez expires_in_minutes — 24 heures au plus — et ne peut pas être retiré avant. Il ouvre la page d’un seul client, en lecture seule : il ne peut rien modifier ni montrer un autre client. Un lien créé avec une clé de test (mf_test_…) affiche des données de test, sous un badge Test data.

Ouvrez un projet → Portal : nom de l’entreprise, logo, thème clair / sombre / automatique, couleurs et rayon des coins, ainsi que les valeurs par défaut — URL de Buy more, URL de Back et durée — pour les liens qui ne les précisent pas. Une case à cocher applique l’apparence à tous les projets de l’organisation.

Dans le tableau Customers, l’action de ligne Create a portal link crée un lien pour ce client sans code — tout comme Portal link dans son onglet Credits.

Doit correspondre exactement au nom d’événement d’un meter existant et actif dans ce projet (sensible à la casse). C’est cette correspondance qui indique à MeterFlow quel compteur cet événement alimente. Aucun meter correspondant → l’API rejette l’événement avec un 404 et rien n’est stocké. Vérifiez l’orthographe exacte sur la page Meters.

Lequel de vos clients l’a fait — la même chaîne d’ID libre que pour les abonnements et les crédits. La cohérence est primordiale : user-842 et USER-842 sont deux clients différents.

La quantité — facultative. Omise, un meter Sum, Max ou Min la lit dans la propriété de l’événement que nomme son champ d’agrégation (votre app l’envoie dans properties) ; sinon l’événement compte pour 1. Son sens dépend de l’agrégation du meter : pour un meter Count la valeur est ignorée (chaque événement compte comme une occurrence) ; pour Sum c’est la quantité à ajouter (42 secondes, 1 300 tokens) ; pour Max/Min c’est la mesure comparée ; un meter Unique count compte les valeurs distinctes de son champ d’agrégation.

Où MeterFlow envoie les événements, p. ex. https://api.acme.dev/meterflow.

Les événements dont cet endpoint est informé : usage.recorded, credit.granted, credit.deducted (une déduction, ou un usage Metered facturé — son transaction_type dit lequel), subscription.created, .updated, .renewed et .canceled, limit.reached, cap.reached, balance.exhausted, et les deux ci-dessous.

Un solde, en crédits. Définissez-le et l’endpoint reçoit aussi balance.low quand le solde d’un client passe en dessous et balance.topped_up quand il repasse au-dessus ; effacez-le et les deux s’arrêtent. Les deux événements vont et viennent avec le seuil, car sans ligne on ne peut pas prévenir un endpoint d’un franchissement.

Celui des cinq par lequel vos clients paient.

Live — le compte de production de votre fournisseur, qui écrit des données live ; Test — son bac à sable, qui écrit des données de test. Un connecteur par fournisseur et par compte.

Le secret avec lequel votre fournisseur signe ses webhooks — pour Chargebee, qui ne signe rien, l’identifiant et le mot de passe qu’il envoie à la place. Il est vérifié à chaque appel et jamais réaffiché : le tableau n’en montre que les quatre derniers caractères.

Affichée dès que le connecteur est créé : collez-la dans les réglages webhook de votre fournisseur.

Quel prix de votre fournisseur — un produit sur Polar, une variante sur Lemon Squeezy, une formule sur Chargebee et Razorpay — place un client sur laquelle de vos formules. Un événement pour un prix sans correspondance est enregistré et ne change rien.

Chaque événement reçu par le connecteur, avec ce qu’il en a fait en une phrase : ce qui a été appliqué, et pourquoi le reste a été ignoré.

Où part l’invitation. MeterFlow envoie un lien qui fonctionne une fois, pendant 7 jours, pour cette adresse seulement : la personne l’ouvre et rejoint — depuis son compte, ou en en créant un via le lien.

Admin — réglages de l’organisation, invitations, clés API, webhooks, connecteurs, projets et facturation. Member — celui qui travaille au quotidien : meters, formules et les pages Subscriptions, Usage et client. Viewer — lecture seule. Il n’y a volontairement pas d’option « owner » : la propriété ne se donne pas par invitation.

Listées sur la page Members jusqu’à ce qu’elles soient acceptées, révoquées ou expirées. Revoke coupe le lien aussitôt.

Sur la ligne de chaque membre, pour les owners et admins. L’appartenance de l’owner et la vôtre ne se changent pas là. Retirer quelqu’un lui ôte l’accès ; son compte, et ce qu’il a créé, restent.