Passer au contenu principal
Cet endpoint a été mis à jour pour inclure les métadonnées d’édition de Publications. Pour en savoir plus sur ces métadonnées, consultez la page de notions de base “Modifier des Publications”. 

​
Flux Decahose

Enterprise Ceci est une API Enterprise disponible uniquement dans le cadre de nos niveaux d’accès gérés. Pour utiliser cette API, vous devez d’abord créer un compte avec notre équipe commerciale Enterprise. En savoir plus Le Decahose fournit, via une connexion de streaming, un échantillon aléatoire de 10 % du X Firehose en temps réel. Cela est réalisé grâce à un algorithme d’échantillonnage en temps réel qui sélectionne les données de manière aléatoire, tout en garantissant une livraison à faible latence au fur et à mesure que les données sont envoyées dans le firehose par X. Voici quelques fonctionnalités disponibles avec Decahose :
  • URL développées et enrichies : - développe entièrement les URL raccourcies et fournit des métadonnées supplémentaires (titre et description de la page)
  • Partitionnement du flux - 2 partitions, chacune contenant 50 % du volume du flux Decahose
  • Fiabilité améliorée - diversité géographique des systèmes backend
Remarque : ces données sont livrées en bloc et ne prennent pas en charge de filtrage supplémentaire (par exemple, par mots-clés). ENTERPRISE

​
Diffusion en continu des mentions J’aime

Ceci est une API Enterprise disponible uniquement dans le cadre de nos niveaux d’accès gérés. Pour utiliser cette API, vous devez d’abord ouvrir un compte avec notre équipe commerciale Enterprise. En savoir plus Les mentions J’aime permettent de savoir qui aime les Publications et fournissent un comptage précis des mentions J’aime. Firehose et Decahose de Gnip peuvent diffuser les mentions J’aime publiques liées aux Publications diffusées via Gnip. Cela offre des mesures d’engagement public et d’audience en temps réel associées à une Publication.   Bien démarrer avec les mentions J’aime Avant de consommer les données relatives aux mentions J’aime, vous devez savoir que :
  • Les mentions J’aime sont fournies via un flux indépendant et distinct
  • Historiquement, les mentions J’aime étaient appelées « Favorites ». La charge utile au format natif enrichi conserve cette nomenclature
  • Les flux n’incluent que les mentions J’aime publiques
    • « Publique » signifie que l’utilisateur qui aime, le créateur de la Publication et la Publication sont tous publics sur la plateforme
  • Les mentions J’aime sont très similaires aux Retweets et représentent un signal public d’engagement
  • Les éléments de la charge utile incluent :
    • L’objet Publication d’origine
    • L’objet acteur qui a créé la Publication d’origine
    • L’objet acteur qui a effectué l’action de mention J’aime
  • Seul le contenu original peut recevoir une mention J’aime
    • Les Retweets ne peuvent pas recevoir de mention J’aime. Une mention J’aime sur un Retweet est appliquée à la Publication d’origine
    • Les Tweets cités peuvent recevoir une mention J’aime
  • Les activités de mention J’aime incluent les enrichissements Gnip applicables (lorsqu’ils sont achetés/appliqués)
  • Produits / fonctionnalités pris en charge
    • Les flux de mentions J’aime prennent en charge la fonctionnalité Backfill (lorsqu’elle est achetée/appliquée)
    • Il n’existe aucune prise en charge de Replay pour les flux de mentions J’aime
    • Il n’existe aucune prise en charge Search ou Historical pour les mentions J’aime
    • Il n’est pas prévu dans l’immédiat d’ajouter la prise en charge des mentions J’aime à PowerTrack
Decahose Charge utile au format natif enrichi 
{
   "id":"43560406e0ad9f68374445f5f30c33fc",
   "created_at":"Thu Dec 01 22:27:39 +0000 2016",
   "timestamp_ms":1480631259353,
   "favorited_status":{
      "created_at":"Thu Dec 01 22:27:16 +0000 2016",
      "id":804451830033948672,
      "id_str":"804451830033948672",
      "text":"@kafammheppduman",
      "source":"\u003ca href=\"http:\/\/x.com\/download\/android\" rel=\"nofollow\"\u003eX pour Android\u003c\/a\u003e",
      "truncated":false,
      "in_reply_to_status_id":803694205163814912,
      "in_reply_to_status_id_str":"803694205163814912",
      "in_reply_to_user_id":2855759795,
      "in_reply_to_user_id_str":"2855759795",
      "in_reply_to_screen_name":"kafammheppduman",
      "user":{
         "id":2855759795,
         "id_str":"2855759795",
         "name":"delirdim kanka",
         "screen_name":"kafammheppduman",
         "location":"sanane",
         "url":"http:\/\/instagram.com\/kafammheppduman",
         "description":"Manit @GalatasaraySk \ud83d\udc9e",
         "translator_type":"none",
         "protected":false,
         "verified":false,
         "followers_count":3702,
         "friends_count":607,
         "listed_count":1,
         "favourites_count":113338,
         "statuses_count":389,
         "created_at":"Sat Nov 01 22:38:25 +0000 2014",
         "utc_offset":null,
         "time_zone":null,
         "geo_enabled":true,
         "lang":"tr",
         "contributors_enabled":false,
         "is_translator":false,
         "profile_background_color":"C0DEED",
         "profile_background_image_url":"",
         "profile_background_image_url_https":"",
         "profile_background_tile":false,
         "profile_link_color":"1DA1F2",
         "profile_sidebar_border_color":"C0DEED",
         "profile_sidebar_fill_color":"DDEEF6",
         "profile_text_color":"333333",
         "profile_use_background_image":true,
       "Profile_image_url": "http:\/\/pbs.twimg.com\/profile_images\/804421763945861121\/v3bp9pnq_normal.jpg",
         "Profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/804421763945861121\/v3bp9pnq_normal.jpg",
         "profile_banner_url":"https:\/\/pbs.twimg.com\/profile_banners\/2855759795\/1480630085",
         "default_profile":true,
         "default_profile_image":false,
         "following":null,
         "follow_request_sent":null,
         "notifications":null
      },
      "geo":null,
      "coordinates":null,
      "place":null,
      "contributors":null,
      "is_quote_status":false,
      "retweet_count":0,
      "favorite_count":0,
      "entities":{
         "hashtags":[],
         "urls":[],
         "user_mentions":[
            {
               "screen_name":"kafammheppduman",
               "name":"delirdim kanka",
               "id":2855759795,
               "id_str":"2855759795",
               "indices":[
                  0,
                  16
               ]
            }
         ],
         "symbols":[]
      },
      "favorited":false,
      "retweeted":false,
      "filter_level":"low",
      "lang":"und"
   },
   "user":{
      "id":774146932365070336,
      "id_str":"774146932365070336",
      "name":"Uyuyan Adam",
      "screen_name":"saykoMenn",
      "location":"Tarsus, T\u00fcrkiye",
      "url":"http:\/\/connected2.me\/pmc1i",
      "description":null,
      "translator_type":"none",
      "protected":false,
      "verified":false,
      "followers_count":414,
      "friends_count":393,
      "listed_count":0,
      "favourites_count":9868,
      "statuses_count":370,
      "created_at":"Fri Sep 09 07:26:26 +0000 2016",
      "utc_offset":null,
      "time_zone":null,
      "geo_enabled":false,
      "lang":"tr",
      "contributors_enabled":false,
      "is_translator":false,
      "profile_background_color":"F5F8FA",
      "profile_background_image_url":"",
      "profile_background_image_url_https":"",
      "profile_background_tile":false,
      "profile_link_color":"1DA1F2",
      "profile_sidebar_border_color":"C0DEED",
      "profile_sidebar_fill_color":"DDEEF6",
      "profile_text_color":"333333",
      "profile_use_background_image":true,
      "Profile_image_url": "http:\/\/pbs.twimg.com\/profile_images\/802992813424201728\/VMzcTL3x_normal.jpg",
      "Profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/802992813424201728\/VMzcTL3x_normal.jpg",
      "profile_banner_url":"https:\/\/pbs.twimg.com\/profile_banners\/774146932365070336\/1480283382",
      "default_profile":true,
      "default_profile_image":false,
      "following":null,
      "follow_request_sent":null,
      "notifications":null
   }
}
Charge utile de suppression de J’aime / d’annulation de J’aime 
{
   "delete":{
      "favorite":{
         "tweet_id":696615514970279937,
         "tweet_id_str":"696615514970279937",
         "user_id":2510287578,
         "user_id_str":"2510287578"
      },
      "timestamp_ms":"1480437031205"
   }
}

​
Guides

​
Récupération et redondance

Introduction  Le streaming de volumes élevés de Publications en temps réel s’accompagne d’un ensemble de bonnes pratiques qui favorisent à la fois la fiabilité des données et leur fidélité intégrale. Lorsque vous consommez des données en temps réel, maximiser le temps de connexion est un objectif fondamental. Lorsque des déconnexions se produisent, il est important de les détecter automatiquement puis de se reconnecter. Après la reconnexion, il est important d’évaluer s’il existe des périodes pour lesquelles il faut effectuer un backfill de données. Le composant qui gère ces détails et consomme les Publications en temps réel n’est qu’une partie d’un système qui comporte des problématiques de réseau, de datastore, de serveur et de stockage. Étant donné la complexité de ces systèmes, une autre bonne pratique consiste à disposer de différents environnements de streaming, avec au minimum des flux séparés pour le développement/les tests et la production. Decahose est livré avec un ensemble de fonctionnalités qui contribuent à cet objectif.
  1. Pour prendre en charge plusieurs environnements, nous pouvons déployer des flux supplémentaires pour votre compte. Ces flux sont indépendants les uns des autres et possèdent un stream_label différent afin de les distinguer.
  2. Pour aider à maintenir une connexion, chaque flux Decahose prend en charge les connexions redondantes. L’architecture la plus courante consiste à ce qu’un flux ait deux connexions, et côté client il y a deux consommateurs indépendants – idéalement sur des réseaux différents. Avec cette conception, il peut y avoir de la redondance au niveau des réseaux côté client, des serveurs et des chemins vers les datastores. Notez qu’une copie complète des données est transmise sur chaque connexion et que le côté client doit être tolérant aux doublons et les gérer.
  3. Un « heartbeat » sera envoyé toutes les 10 secondes ; toutefois, avec le flux Decahose, le volume de données est suffisamment élevé pour qu’une durée même courte (par exemple, quelques secondes) sans Publications puisse indiquer un problème de connexion. Par conséquent, à la fois un « silence de données » et l’absence de heartbeat peuvent être utilisés pour détecter une déconnexion.
Étant donné que des déconnexions se produiront, le flux Decahose dispose d’une fonctionnalité dédiée de récupération et de backfill pour aider à récupérer les données manquées en raison de déconnexions et d’autres problèmes opérationnels.

​
Flux supplémentaires

Disposer de flux Decahose supplémentaires est un autre moyen d’accroître la fiabilité de votre solution. Chaque flux supplémentaire est complètement indépendant, avec son propre endpoint. Chaque flux se voit attribuer son propre stream_label, et ce label, avec votre nom de compte, fait partie de l’URL de ce flux. Voir l’exemple ci‑dessous : https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json La convention la plus courante consiste à disposer d’un flux en temps réel dédié à votre système de production, et d’un flux supplémentaire disponible pour le développement et les tests. Disposer d’un flux de test/développement permet aux clients Decahose d’avoir un flux pour tester les mises à jour de leurs clients consommateurs. Bien que n’importe quel label (unique) puisse être attribué à un flux, une convention consiste à utiliser « prod » pour le flux de production, et « dev » ou « sandbox » pour un flux de développement supplémentaire. Le nombre de flux, et leurs labels uniques, est configurable par votre responsable de compte. Connexions redondantes Une connexion redondante vous permet simplement d’établir plus d’une connexion simultanée au flux de données. Cela fournit de la redondance en vous permettant de vous connecter au même flux avec deux consommateurs distincts, recevant les mêmes données via les deux connexions. Ainsi, votre app dispose d’un basculement à chaud pour diverses situations, par exemple lorsqu’un flux est déconnecté ou lorsque le serveur principal de votre app tombe en panne. Le nombre de connexions autorisées pour un flux donné est configurable par votre responsable de compte. Pour utiliser un flux redondant, connectez‑vous simplement à la même URL que celle utilisée pour votre connexion principale. Les données de votre flux seront envoyées via les deux connexions, les deux connexions de flux étant représentées sur le tableau de bord du flux. Notez qu’aux fins de facturation, nous dédupliquons les décomptes d’activités que vous recevez via plusieurs connexions de sorte que vous ne soyez facturé qu’une seule fois pour chaque activité unique. Étant donné que Decahose a deux partitions, voici ci‑dessous un exemple du fonctionnement du comptage des connexions : Connect to decahose partition=1 Connect to decahose partition=1 Connect to decahose partition=2 La situation ci‑dessus donne un total de trois connexions – deux connexions à partition=1 et une connexion à partition=2. Normalement, vous voudriez le même nombre de connexions pour chaque partition, donc cet exemple illustre une situation où la connexion redondante à partition=2 a été interrompue et où vous souhaiterez enquêter davantage. Récupération

​
Présentation

Recovery est un outil de récupération de données (à ne pas utiliser pour la collecte principale de données) qui fournit un accès en streaming à une fenêtre glissante de 5 jours de données historiques récentes de X. Il doit être utilisé pour récupérer des données dans les scénarios où votre application cliente manque des données dans le flux en temps réel, que ce soit en raison d’une déconnexion de courte durée ou de tout autre scénario où vous ne parvenez pas à ingérer des données en temps réel pendant une certaine période.

​
Utilisation de Recovery

Avec le flux Recovery, votre App peut lui envoyer des requêtes qui fonctionnent de la même manière que les requêtes vers les flux en temps réel. Toutefois, votre App doit spécifier dans l’URL des paramètres indiquant la fenêtre temporelle que vous demandez. En d’autres termes, une requête Recovery demande à l’API « Publications de l’heure A à l’heure B ». Ces Publications sont ensuite livrées via votre connexion de streaming d’une manière qui imite le flux en temps réel, mais à un rythme légèrement inférieur à celui du temps réel. Voir ci‑dessous pour un exemple : “https://stream-data-api.x.com/stream/powertrack/accounts/someAccountName/publishers/twitter/powertrack.json?startTime=2023-07-05T17:09:12.070Z” Les Publications sont livrées en commençant par la première minute (la plus ancienne) de la période spécifiée, puis en continuant chronologiquement jusqu’à la dernière minute. À ce moment‑là, un message « Recovery Request Completed » est envoyé via la connexion, puis la connexion est fermée par le serveur. Si votre requête commence à un moment de la journée où peu ou pas de résultats correspondants se sont produits, il est probable qu’un certain temps s’écoule avant la livraison des premiers résultats : les données seront livrées lorsque Recovery trouvera des correspondances dans la portion de l’archive en cours de traitement à ce moment‑là. Lorsque aucun résultat n’est disponible à livrer, le flux continue d’envoyer des retours chariot, ou « heartbeats », via la connexion pour éviter que votre connexion n’expire. Recovery est conçu comme un outil permettant de récupérer facilement les données manquées en raison de courtes déconnexions, et non pour de très longues périodes comme une journée entière. Si vous devez récupérer des données sur de longues périodes, nous vous recommandons de scinder les requêtes longues en fenêtres temporelles plus courtes (par exemple, deux heures) afin de réduire le risque de déconnexion en cours de requête en raison de la volatilité de la connexion Internet ou d’autres raisons, et d’offrir une meilleure visibilité sur l’avancement des requêtes longues.

​
Disponibilité des données

Vous pouvez utiliser la fonctionnalité Recovery pour récupérer les données manquées au cours des 24 dernières heures si vous n’êtes pas en mesure de vous reconnecter dans la fenêtre de backfill de 5 minutes. La fonctionnalité de streaming Recovery vous permet de bénéficier d’une fenêtre de backfill étendue de 24 heures. Recovery vous permet de « récupérer » la période pendant laquelle des données ont été manquées. Un flux de recovery est démarré lorsque vous effectuez une requête de connexion à l’aide des paramètres de requête start_time et end_time. Une fois connecté, Recovery va à nouveau diffuser la période indiquée, puis se déconnectera.   Vous pourrez effectuer 2 requêtes simultanées à Recovery au même moment, c’est‑à‑dire « deux jobs de recovery ». Recovery fonctionne techniquement de la même manière que le backfill, à ceci près qu’une heure de début et une heure de fin sont définies. Une période de recovery correspond à une seule plage temporelle.

​
Backfill

Pour demander un backfill, vous devez ajouter un paramètre backfillMinutes=N à votre requête de connexion, où N est le nombre de minutes (1-5, nombres entiers uniquement) à rattraper au moment de l’établissement de la connexion. Par exemple, si vous êtes déconnecté pendant 90 secondes, vous devez ajouter backfillMinutes=2 à votre requête de connexion. Étant donné que cette requête fournira un backfill de 2 minutes, y compris pour la période de 30 secondes précédant votre déconnexion, votre application consommatrice doit être tolérante aux données en double. Un exemple d’URL de requête de connexion Decahose, demandant un backfill de 5 minutes vers la partition 1, ressemble à ceci : https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1&backfillMinutes=5 REMARQUES :
  • Vous avez la possibilité d’utiliser systématiquement « backfillMinutes=5 » lors de la connexion, puis de gérer toutes les données en double qui sont fournies.
  • Si vous êtes déconnecté pendant plus de cinq minutes, vous pouvez récupérer les données à l’aide de Recovery.
Récupération après une déconnexion Redémarrer et se remettre d’une déconnexion implique plusieurs étapes :
  • Déterminer la durée de la période de déconnexion.
    • 5 minutes ou moins ?
      • Si vous avez activé Backfill pour le flux, préparez une requête de connexion avec le paramètre « backfillMinutes » approprié.
    • Plus de 5 minutes ?
      • Si vous disposez d’un flux Recovery, effectuez une requête Recovery pour la période de temps déconnectée (idéalement avec votre jeu de règles temps réel actuel, en utilisant l’API Rules si nécessaire).
  • Demander une nouvelle connexion.
Lorsque vous rencontrez des déconnexions ou des temps d’arrêt, voici des stratégies pour atténuer et vous remettre de ce scénario :
  1. Implémenter le backfill
    Le backfill vous permet de vous reconnecter à un point antérieur à la déconnexion d’une connexion de flux et couvre les déconnexions jusqu’à 5 minutes. Il est implémenté en incluant un paramètre dans la requête de connexion.
  2. Consommer un flux redondant depuis un autre emplacement
    Si le flux redondant peut être diffusé dans le même environnement temps réel, avec déduplication des données, vous éliminerez le besoin de récupération, sauf si le flux normal ET le flux redondant subissent simultanément un temps d’arrêt ou des déconnexions. Si le flux redondant ne peut pas être diffusé en direct dans l’environnement de production, il peut être écrit dans un stockage de données « d’urgence » distinct. Ensuite, en cas de déconnexions ou de temps d’arrêt sur la connexion de flux principale, votre système disposera de données pour compléter votre base de données principale pour la période pendant laquelle des données manquent.
  3. Implémenter Recovery
    Lorsque des déconnexions ou des temps d’arrêt affectent à la fois le flux principal et le flux redondant, utilisez Decahose Recovery pour récupérer toutes les données manquées. L’API fournit une fenêtre glissante couvrant 5 jours d’archive, et il est préférable de l’utiliser en demandant au maximum une heure de cette fenêtre à la fois, puis en la diffusant. Cela se fait en parallèle du flux temps réel. Notez que nous n’avons pas de solutions pour récupérer les données Decahose au-delà de la fenêtre de 5 jours fournie par Recovery, il est donc important pour vous d’utiliser un flux redondant afin de disposer d’une copie complète des données de votre côté en cas de temps d’arrêt significatif de votre côté.
Lorsque vous détectez des volumes de données stockées anormaux :
Voici quelques façons possibles de détecter des données manquantes alors qu’aucune déconnexion ou temps d’arrêt ne s’est produit…
  1. Compter les Publications entrantes
    Votre système doit compter le nombre brut de Publications que vous recevez tout au début de votre application d’ingestion, puis fournir un moyen de comparer ces nombres au nombre de Publications qui atteint votre stockage de données final. Toute différence peut être surveillée et alerter votre équipe sur les problèmes provoquant la perte de données après leur réception.
  2. Analyser les volumes stockés anormaux
    Vous pouvez également analyser les volumes de données stockées dans votre base de données finale pour rechercher des baisses anormales. Cela peut également indiquer des problèmes, même s’il y aura probablement des circonstances dans lesquelles des baisses de volume sont normales (par exemple si la plateforme X est indisponible et que les personnes ne peuvent pas créer de Publications pendant un certain temps).

​
Référence de l’API

​
Flux Decahose

Aller à, sur cette page : Méthodes Authentification GET /{stream-type}/:stream Replay API

​
Méthodes

MéthodeDescription
GET /{stream-type}/:streamConnectez-vous au flux de données

​
Authentification

Toutes les requêtes vers les API Volume Stream doivent utiliser l’authentification HTTP Basic, construite à partir d’une combinaison valide d’adresse e‑mail et de mot de passe utilisée pour vous connecter à votre compte sur console.gnip.com. Les identifiants doivent être transmis dans l’en-tête Authorization pour chaque requête. Assurez‑vous donc que votre client ajoute l’en-tête HTTP Authorization: Basic (avec les identifiants encodés sur HTTPS) à toutes les requêtes API.

​
GET :stream

Établit une connexion persistante au flux Firehose, via lequel les données en temps réel sont transmises.

​
Spécifications de la requête

Méthode de requêteHTTP GET
Type de connexionKeep-Alive

Cela doit être spécifié dans l’en-tête de la requête.
URLIndiquée sur la page d’aide de l’API du flux de votre tableau de bord, en utilisant la structure suivante :

Decahose :

https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1
Partition (obligatoire)partition=\{#} - Le partitionnement est désormais requis pour consommer l’intégralité du flux. Vous devez vous connecter au flux avec le paramètre de partition spécifié. Vous trouverez ci-dessous le nombre de partitions par flux :

* Decahose : 2 partitions
CompressionGzip. Pour vous connecter au flux en utilisant la compression Gzip, envoyez simplement un en-tête Accept-Encoding dans la requête de connexion. L’en-tête doit être le suivant :

Accept-Encoding: gzip
Encodage des caractèresUTF-8
Format de réponseJSON. L’en-tête de votre requête doit spécifier le format JSON pour la réponse.
Limite de débit10 requêtes par période de 60 secondes.
Paramètre BackfillSi vous avez acheté un flux avec Backfill activé, vous devrez ajouter le paramètre “backfillMinutes” à la requête GET pour l’activer.
Délai d’attente de lectureConfigurez un délai d’attente de lecture sur votre client et assurez-vous qu’il est défini sur une valeur supérieure à 30 secondes.
Prise en charge des modifications de TweetTous les objets Tweet incluront des métadonnées de modification de Tweet décrivant l’historique des modifications du Tweet. Consultez la page de notions fondamentales “Edit Tweets” pour plus de détails.

​
Réponses

Les réponses suivantes peuvent être renvoyées par l’API pour ces requêtes. La plupart des codes d’erreur sont renvoyés avec une chaîne contenant des détails supplémentaires dans le corps de la réponse. Pour les réponses dont le code n’est pas 200, les clients doivent tenter de se reconnecter.
StatutTexteDescription
200SuccèsLa connexion a été ouverte avec succès et les nouvelles activités seront envoyées au fur et à mesure de leur arrivée.
401Non autoriséL’authentification HTTP a échoué en raison d’identifiants invalides. Connectez-vous à console.gnip.com avec vos identifiants pour vous assurer que vous les utilisez correctement dans votre requête.
406Non acceptableEn général, cela se produit lorsque votre client n’inclut pas correctement les en-têtes pour accepter l’encodage gzip du flux, mais cela peut également se produire dans d’autres circonstances.

Contiendra un message JSON similaire à « Cette connexion nécessite la compression. Pour activer la compression, envoyez un en-tête “Accept-Encoding: gzip” dans votre requête et soyez prêt à décompresser le flux au fur et à mesure de sa lecture côté client. »
429Limitation de débitVotre application a dépassé la limite de requêtes de connexion.
503Service indisponibleProblème de serveur Twitter. Reconnectez-vous en utilisant une stratégie de reconnexion avec backoff exponentiel. Si aucun avis concernant ce problème n’a été publié sur la X API Status Page, contactez le support ou le service d’urgence si vous ne parvenez pas à vous connecter après 10 minutes.

​
Exemple de requête cURL

L’exemple de requête suivant est réalisé à l’aide de cURL en ligne de commande. Notez cependant que ces requêtes peuvent également être envoyées avec le langage de programmation de votre choix : 
curl --compressed -v -uexample@customer.com "https://gnip-stream.x.com/stream/firehose/accounts/:account\_name/publishers/twitter/:stream\_label.json?partition={#}"

​
API Replay

L’API Replay est un complément important aux flux Volume en temps réel. Replay est un outil de récupération de données qui fournit un accès en streaming à une fenêtre glissante de données historiques récentes sur X.