Créer une souscription prompt

Quand l'utiliser

Une souscription livre un rapport PostHog par email ou Slack selon un calendrier récurrent. Il en existe trois sortes, distinguées par le champ que vous définissez — le type est dérivé et retourné en tant que resource_type en lecture seule :

• insight — snapshots périodiques d'un insight existant (resource_type: "insight")
• dashboard — snapshots périodiques des tuiles d'un dashboard (resource_type: "dashboard")
• prompt — un rapport généré par IA récurrent à partir d'un prompt en langage naturel : un LLM planifie et exécute HogQL sur les données du projet et synthétise un rapport markdown frais à chaque tick (resource_type: "ai_prompt")

Utilisez cette skill pour le type prompt — c'est-à-dire quand l'utilisateur souhaite un résumé récurrent par IA de X (sur n'importe quel rythme — quotidien, hebdomadaire, mensuel, annuel) plutôt qu'un snapshot récurrent d'un insight/dashboard existant, ou un rapport unique ponctuel. Choisissez une souscription prompt quand la valeur est l'analyse elle-même (le LLM décidant quoi interroger et la rédaction), pas un graphique figé qu'il a déjà construit. Pour une souscription insight/dashboard, définissez plutôt insight/dashboard à la place de prompt et les filtres IA ci-dessous ne s'appliquent pas.

Cette skill couvre la création de la souscription. Une fois qu'elle existe, vous gérez son cycle de vie avec les mêmes outils subscriptions-* (voir ci-dessous) : l'énumérer, l'éditer/désactiver/réactiver, envoyer une livraison test, ou la supprimer.

Outils

Ce dont vous avez besoin avant d'appeler

L'endpoint applique trois filtres à la création et retourne 400 si l'un échoue :

1. PostHog Cloud, ou DEBUG=true — les déploiements production auto-hébergés ne sont pas éligibles (l'appel LLM emprunte une clé gérée par PostHog).
2. Approbation « AI data processing » au niveau org — doit être activée dans Org settings → Data → AI data processing. L'utilisateur doit d'abord opter pour les fonctionnalités IA de l'organisation.
3. Souscriptions prompt activées pour l'organisation — un flag de déploiement géré par PostHog. S'il est désactivé, l'org n'a pas encore reçu d'accès ; dites à l'utilisateur de contacter PostHog pour l'activer (il n'y a pas de toggle en libre-service).

Si l'un des trois manque, arrêtez-vous et dites à l'utilisateur lequel corriger — rappeler l'outil ne servira à rien.

Votre token d'accès a aussi besoin du scope query:read en plus de subscription:write : une souscription prompt exécute HogQL généré par LLM sur les données du projet, donc le backend exige l'accès aux queries pour la créer, l'éditer/réactiver, envoyer un test, ou la supprimer. Un token subscription:write uniquement est rejeté avec un 403.

Arguments obligatoires

prompt: "..."                         # ≤4000 caractères ; le définir (sans insight/dashboard) en fait une souscription prompt → resource_type "ai_prompt"
target_type: "email" | "slack"        # webhook est rejeté pour les souscriptions prompt
target_value: "..."                   # emails séparés par des virgules, ou "<channel_id>|<channel_name>"
frequency: "daily" | "weekly" | "monthly" | "yearly"
interval: 1                            # 1 = chaque tick ; 2 = chaque autre tick ; etc.
start_date: "2026-09-15T09:00:00Z"   # ancre la récurrence + l'heure du jour ; n'a pas besoin d'être dans le futur — le scheduler livre l'occurrence suivante
title: "..."                          # nom d'affichage dans la liste des souscriptions

Il n'y a pas d'argument resource_type à envoyer — le type est dérivé de quel champ vous définissez (prompt ⇒ rapport IA) et retourné en tant que resource_type en lecture seule.

Arguments optionnels

byweekday: ['monday', 'wednesday'] # hebdomadaire uniquement — jours où la rrule se déclenche
bysetpos: 1 # très utile pour le mensuel ; requiert byweekday — par ex. byweekday:['monday']+bysetpos:-1 = dernier lundi
count: 10 # plafonne les livraisons totales
until_date: '2026-12-31T00:00:00Z' # arrête à/avant cette date
integration_id: 42 # Slack uniquement — obligatoire ; de integrations-list (voir « Cible Slack »)

Cible Slack

target_value doit être <channel_id>|<channel_name> (le format que l'intégration retourne). Construisez-le en trois étapes :

1. posthog:integrations-list filtré par kind=slack → choisissez l'id de l'intégration Slack.
2. posthog:integrations-channels-retrieve avec cet id → choisissez un canal ; il retourne chaque id et name du canal, que vous assemblez dans target_value comme <id>|<name>.
3. Passez l'id de cette intégration comme integration_id — la souscription est épinglée à une intégration Slack spécifique afin que les reconnexions ailleurs ne réorientent pas accidentellement les livraisons.

Exemples

Résumé IA hebdomadaire le lundi matin par email

prompt: 'Top events semaine sur semaine, avec les plus fortes baisses et tout nouveau mode d'échec noté.'
target_type: email
target_value: founders@acme.example
frequency: weekly
interval: 1
byweekday: ['monday']
start_date: '2026-09-14T08:00:00Z'
title: 'Weekly product pulse'

Rapport Slack quotidien à 9h

prompt: "Sign-ups d'hier, d'où ils viennent, et les erreurs rencontrées lors de l'onboarding."
target_type: slack
target_value: 'C0123456789|growth-updates' # <channel_id>|<channel_name> ; seul le channel id est utilisé, le nom est cosmétique
integration_id: 42
frequency: daily
interval: 1
start_date: '2026-09-15T09:00:00Z'
title: 'Daily onboarding watch'

Pièges

• Le type est immuable. Il est dérivé de quelle relation est définie, donc vous ne pouvez pas transformer une souscription insight ou dashboard en souscription prompt après coup (ou vice versa) — un PATCH ajoutant un prompt à une souscription insight est rejeté. Choisissez le bon type à la création.
• Réactiver une souscription prompt précédemment auto-désactivée a deux préconditions, toutes deux appliquées au PATCH : (1) un prompt valide — déjà persisté sur la ligne, ou un nouveau dans le corps du PATCH (donc un {"enabled": true} brut fonctionne quand le prompt stocké est encore valide, mais est rejeté quand la raison de la désactivation était un prompt invalide jusqu'à ce que vous en fournissiez un bon) ; et (2) le créateur original est toujours un utilisateur actif — si ce compte a été désactivé, la souscription ne peut pas être réactivée du tout (aucun prompt ne servira ; recréez-la plutôt).
• next_delivery_date est calculée par le serveur à partir de la rrule. N'essayez pas de la définir manuellement — elle est en lecture seule. La première livraison se déclenche à la première occurrence de start_date qui est au moins un court buffer (actuellement ~15 minutes) dans le futur, donc un start_date de seulement quelques secondes d'avance passe à l'occurrence suivante.
• Les défaillances d'envoi transitoires sont réessayées ; seules les défaillances permanentes auto-désactivent. Une défaillance transitoire (limite de débit Slack, blip SMTP, réseau) échoue cette livraison et est renvoyée par Temporal au cours de l'exécution, puis re-déclenche au prochain tick programmé — elle n'auto-désactive pas la souscription, donc un canal persistant défaillant continuera à réessayer à chaque tick jusqu'à ce que vous le corrigiez. Seules les causes permanentes/structurelles auto-désactivent : une intégration Slack déconnectée, une permission de canal révoquée, un prompt invalide, ou un consentement révoqué au traitement des données IA. (Pour l'email multi-destinataires, une livraison échoue seulement quand chaque destinataire échoue ; les succès partiels s'envoient quand même.) Au sein d'une seule exécution de livraison, le markdown rendu est mis en cache, donc les renvois Temporal de cette exécution ne re-lancent pas le pipeline LLM — mais chaque nouveau tick programmé génère un rapport frais.

Après sa création

subscriptions-list retournera la nouvelle ligne. Confirmez resource_type: "ai_prompt", enabled: true, next_delivery_date est dans le futur, et prompt correspond à ce que vous avez envoyé. Le premier tick programmé exécutera le pipeline planner → HogQL → synthesis et enverra le markdown rendu par email/Slack.