L’export vers l’entrepôt de données place les données 50heads de votre organisation là où votre équipe data travaille déjà. Deux façons de faire :

  • Des fichiers dans votre propre bucket. Toutes les heures, toutes les six heures ou chaque jour, 50heads écrit les nouveautés dans votre bucket Amazon S3, Cloudflare R2 ou Google Cloud Storage. Chargez les fichiers dans Snowflake, BigQuery, Redshift ou tout autre entrepôt.
  • Le flux d’événements. Votre propre tâche, ou un outil comme Airbyte, lit les événements via l’API, page par page, et seulement les nouveautés à chaque fois.

Nous ouvrons l’export vers l’entrepôt aux organisations progressivement. Si vous ne voyez pas Export vers l’entrepôt de données dans Paramètres, puis Organisation, il n’est pas encore activé pour votre organisation. Écrivez-nous si vous le souhaitez.

Ce que vous pouvez envoyer

  • Les événements : les mêmes que ceux envoyés par les webhooks. Questions réservées, terminées, avec moins de réponses que prévu, annulées ou refusées, avec le résumé des résultats ; crédits achetés, presque épuisés ou bientôt expirés ; approbations ; personnes et équipes qui arrivent ou partent. Chaque événement a un id, un type, createdAt, updatedAt et ses data. Les événements ne disent jamais qui a répondu.
  • Le journal d’audit : qui a fait quoi dans l’organisation, comme dans le journal d’audit. Le journal d’audit doit aussi être activé pour votre organisation.

Ajouter un bucket

Les propriétaires et administrateurs d’une des équipes de l’organisation peuvent ajouter jusqu’à cinq buckets. Ajouter, mettre en pause, remplacer les clés et supprimer demandent de confirmer à nouveau que c’est bien vous. Choisissez Confirmer que c’est vous quand on vous le demande. La confirmation vaut 10 minutes.

  1. Dans votre compte cloud, créez une clé qui peut seulement écrire des fichiers dans le bucket, sous le dossier choisi. Pour Google Cloud Storage, créez une clé HMAC pour un compte de service ; pour Cloudflare R2, un jeton d’API R2 avec un accès en écriture au bucket.
  2. Allez dans Paramètres, puis Organisation, et choisissez Ouvrir l’export vers l’entrepôt.
  3. Sous Ajouter une destination, donnez-lui un nom et choisissez où : Amazon S3 (avec sa région, par exemple eu-west-2), Cloudflare R2 (avec votre ID de compte Cloudflare) ou Google Cloud Storage.
  4. Saisissez le bucket et le dossier, par exemple 50heads/.
  5. Cochez ce qui est envoyé et choisissez la fréquence.
  6. Saisissez l’ID de clé d’accès et la clé secrète, puis choisissez Tester et enregistrer.

À l’enregistrement, nous écrivons un petit fichier de test, _50heads/connection-test.json, dans le dossier. Si le bucket le refuse, rien n’est enregistré et la page vous dit pourquoi. Nous conservons les clés chiffrées et ne les affichons plus jamais. Le premier export a lieu dans les cinq minutes.

Ce qui arrive dans le bucket

Chaque export écrit des JSON Lines (un objet par ligne), puis un manifeste :

  • 50heads/events/dt=2026-10-13/<export>-0001.jsonl
  • 50heads/audit/dt=2026-10-13/<export>-0001.jsonl
  • 50heads/manifests/<heure>-<export>.json

Le manifeste liste chaque fichier de l’export, avec son nombre de lignes et une somme SHA-256. Chargez les fichiers qu’un manifeste liste. Un fichier sans manifeste provient d’un export qui a échoué ; le suivant réécrit ses lignes.

Chaque export n’envoie que ce qui est nouveau depuis le dernier export réussi. Chargez par id pour qu’un événement reçu deux fois ne soit gardé qu’une fois. Les fichiers Parquet ne sont pas encore proposés.

Quand un export échoue

La page montre les exports récents de chaque bucket et la dernière erreur. Après trois échecs d’affilée, le bucket est marqué En échec, le journal d’audit l’enregistre et les propriétaires et administrateurs de l’organisation reçoivent un e-mail. Nous continuons d’essayer : le prochain export réussi reprend là où le dernier export réussi s’est arrêté. Rien n’est donc perdu tant que cela refonctionne dans les 90 jours, la durée pendant laquelle nous gardons les événements.

Utilisez Tester la connexion pour vérifier les clés, et Exporter maintenant pour lancer un export dans les cinq minutes.

Lire le flux d’événements

Créez une clé API avec la portée events:read, ou donnez-la à un compte de service.

  • GET /v1/events lit le compte auquel appartient la clé.
  • GET /v1/organizations/current/events lit toutes les équipes de l’organisation. Il faut la clé d’un administrateur de l’organisation ou un compte de service.

Les événements arrivent du plus ancien au plus récent. Chaque page comporte un nextCursor : renvoyez-le comme cursor pour la page suivante, et gardez le dernier pour ne lire que les nouveautés la fois suivante. since permet de commencer à une heure donnée.

Une source Airbyte pour le flux se trouve dans notre dépôt de code, dans packages/airbyte-source-50heads : importez son manifest.yaml dans le Connector Builder d’Airbyte. Toute l’API est décrite dans la documentation développeurs.

Qui voit quoi

  • Seuls les propriétaires et administrateurs de l’organisation voient la page d’export.
  • Les clés API et les comptes de service avec organization:read peuvent lire l’état de chaque bucket, jamais ses clés, et ne peuvent rien modifier.
  • Le serveur MCP (l’outil organization, action warehouse) et la ligne de commande (50heads org warehouse) montrent le même état.