account/monitors

La création d’un moniteur et la première référence sont gratuites. Un cycle de 30 jours est facturé dès que le moniteur devient actif. Le prix dépend de l’intervalle de vérification et couvre toutes les vérifications que l’intervalle prévoit dans un cycle.

Un intervalle entre deux paliers coûte autant que le palier plus fréquent suivant : tous les quatre jours coûte autant que tous les trois jours.

Des vérifications supplémentaires ont lieu surtout quand tu raccourcis l’intervalle en cours de cycle. Chaque vérification supplémentaire réussie coûte le montant du tableau.

Après 30 jours, le cycle se renouvelle automatiquement au prix alors en vigueur. Les vérifications échouées ne coûtent rien. Si tu mets en pause, archives ou changes l’intervalle, nous ne remboursons rien.

Chaque compte peut avoir jusqu’à 50 moniteurs en même temps, un par entreprise. En 24 heures, tu peux créer jusqu’à 50 moniteurs ; les moniteurs archivés comptent aussi.

Tu obtiens gratuitement le prix d’un intervalle avec GET /v1/account/monitoring/pricing, ici pour une vérification tous les sept jours :

1. Création. Tu indiques l’entreprise, l’intervalle de vérification et au moins un endpoint webhook vérifié. Le moniteur démarre avec le statut initializing.
2. Référence. Nous enregistrons les signals des derniers jours comme connus. Ils ne sont pas livrés : tu ne reçois que ce qui est nouveau ensuite.
3. Activation. Nous facturons le cycle, le moniteur devient active et vérifie immédiatement une première fois.
4. Vérification. Ensuite, il vérifie à l’intervalle choisi. Chaque nouveau signal déclenche un message par moniteur vers tes endpoints webhook.
5. Renouvellement. Après chaque cycle, le suivant est facturé automatiquement, tant que ton solde le couvre.

L’intervalle de vérification est compris entre 1 et 30 jours. L’heure exacte d’une vérification peut varier d’une heure. Chaque vérification regarde quelques jours en arrière, pour que les inscriptions publiées tardivement arrivent aussi.

Un moniteur livre les thèmes Signals de ton plan : cinq dans chaque compte, Insolvabilités avec Pro, Transformations & fusions-acquisitions avec Max. Un webhook porte dans le champ data.signal le même signal que signals.

Pour les moniteurs en pause et les erreurs, status_reason explique pourquoi, par exemple no_verified_endpoint ou insufficient_cycle_floor.

Tous les chemins se trouvent sous /v1/account. Tu lis et écris avec ta clé API dans le header x-api-key.

Chaque requête d’écriture nécessite le header Idempotency-Key, une valeur unique par opération, idéalement un UUID. Sans lui, l’API répond 428.

Si tu répètes une requête avec la même clé et les mêmes données dans les 24 heures, tu reçois la réponse enregistrée. Elle porte le header Idempotency-Status: replayed. Ainsi, une erreur réseau ne crée pas de second moniteur.

Cela vaut aussi pour les réponses d’erreur. Pour une nouvelle tentative après une correction, utilise donc une nouvelle clé. La même clé avec des données différentes renvoie 409.

Jusqu’à 128 caractères sont autorisés : lettres, chiffres et . _ : -. Le premier caractère est une lettre ou un chiffre. Une clé dans tout autre format renvoie 400.

Il te faut l’entity_id de l’entreprise et au moins un endpoint webhook vérifié, voir account/webhook-endpoints.

L’API répond 202 : le moniteur est créé, la référence et l’activation s’exécutent en arrière-plan. meta.billing.charged_credits montre que rien n’a été facturé pour cela.

GET /v1/account/monitors renvoie jusqu’à 100 moniteurs sous monitors, avec total. Les moniteurs archivés ne figurent pas dans la liste.

GET /v1/account/monitors/{id} montre aussi le cycle en cours dans billing_cycle et les dernières vérifications dans recent_runs.

PATCH /v1/account/monitors/{id} change l’intervalle de vérification. La vérification suivante a alors lieu au nouvel intervalle, compté à partir du changement.

Le cycle en cours conserve son prix et ses vérifications incluses. Le nouveau prix s’applique à partir du cycle suivant. Un intervalle plus court peut déclencher des vérifications supplémentaires dans le cycle en cours.

POST …/{id}/pause arrête un moniteur actif. Le cycle payé continue de courir, et rien n’est remboursé.

POST …/{id}/resume reprend un moniteur en pause ou en erreur. Nous vérifions de nouveau les endpoints webhook, le solde et le prix.

Dans le cycle payé en cours, la reprise ne coûte rien. Si le cycle est écoulé, un nouveau cycle commence maintenant au prix actuel. meta.request_credit_cost indique le montant.

S’il manque par exemple un endpoint webhook vérifié, l’API répond quand même 200, mais avec meta.activated: false. Le statut du moniteur et status_reason en indiquent la raison.

Si le prix a changé, un moniteur actif s’arrête à la fin du cycle avec pricing_consent_required. Avec resume, tu acceptes le nouveau prix.

DELETE …/{id} archive définitivement le moniteur. C’est irréversible et rien n’est remboursé.

Les erreurs ont la structure {"error": "…", "meta": {"message": "…"}}. Dans ton programme, vérifie la valeur de error. Le texte dans meta.message est en anglais et peut changer. Les erreurs ne coûtent rien.