> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Vue d'ensemble
> Vue d'ensemble des endpoints REST de la Data API de Kameleoon pour récupérer et écrire des événements de visiteur, des données de produit et des données de map externes.
La **Data API** est une API REST qui récupère ou écrit des données stockées sur les serveurs distants de Kameleoon. Utilisez les endpoints disponibles pour :
* Récupérer les événements de visite pour un visiteur donné.
* Envoyer des événements de visite supplémentaires pour un visiteur donné, tels que des événements de conversion hors ligne.
* Envoyer et récupérer des données de produit pour un sitecode donné.
* Stocker des données supplémentaires pour un visiteur donné, telles que des données CRM ou de segmentation.
## Endpoints de la Data API
**Les endpoints se répartissent en trois catégories principales de données :**
### Endpoints Visit
Les **endpoints Visit** récupèrent et envoient des événements (conversions, custom data, segments et plus) pour un code visiteur donné. Utilisez ces endpoints pour importer dans Kameleoon des données d'achat hors ligne, telles que les achats en magasin physique.
* [GET /visit/visitor](/api-reference/visit/get-visitor-data) : cet endpoint récupère les données de visites collectées par Kameleoon, telles que les expériences et personnalisations déclenchées pour l'utilisateur ou les segments ciblés.
L'accès à cet endpoint nécessite la solution Kameleoon [Feature Experimentation](../../feature-experimentation/targeting-and-segmentation/native-segmentation#handling-data-in-kameleoon-sdks). Pour plus d'informations, contactez le Customer Success Manager.
* [POST /visit/forget](/api-reference/visit/remove-data-for-several-visitors) : cet endpoint supprime les données de plusieurs visiteurs.
* [POST /visit/events](/api-reference/visit/send-visitor-events) : cet endpoint publie des données pour un visiteur donné, telles que des événements de conversion et de page vue.
### Endpoints Product
Les **endpoints Product** récupèrent et envoient des données de produit pour un sitecode donné. Utilisez ces endpoints pour enregistrer des événements liés aux produits tels que les vues, les ajouts au panier ou les achats, ou pour obtenir des statistiques sur des produits spécifiques, comme l'historique du nombre d'achats ou de vues.
* [POST /product/events](/api-reference/product/send-product-events) : cet endpoint publie des attributs de produit et des événements (vue, ajout au panier et achat) pour plusieurs produits. L'[Activation API](../activation-api-js/api-reference/api-reference#kameleoonapiproducts) utilise les méthodes `obtainProductData` et `obtainProductInteractions` pour récupérer et utiliser ces données à des fins de ciblage ou de recommandations.
* [GET /product/productCounters](/api-reference/product/get-product-counters) : cet endpoint récupère les comptages (nombre de vues, quantités ajoutées au panier, quantités de transactions) pour plusieurs produits.
* [GET /product/productData](/api-reference/product/get-product-data) : cet endpoint récupère les attributs de plusieurs produits.
Vous devez avoir accès au module Product Recommendation ou au module complémentaire Product Targeting. Tous deux s'intègrent à la solution [Web Experimentation](https://www.kameleoon.com/en/platform/ab-testing-client-side). Pour plus d'informations, contactez le Customer Success Manager.
### Endpoints Map
Les **endpoints Map** stockent des données supplémentaires pour une clé donnée (généralement un code visiteur ou un ID utilisateur interne). L'[Activation API](../activation-api-js/api-reference/api-reference#retrievedatafromremotesource) et tous les [SDK](../../sdks/web-sdks/nodejs-sdk#getremotedata) utilisent la méthode `retrieveDataFromRemoteSource` pour récupérer et utiliser ces données à des fins de ciblage et de segmentation. Utilisez l'endpoint `map` pour récupérer les données stockées pour une clé spécifique.
* [GET /map/map](/api-reference/map/get-data-for-a-key) : cet endpoint récupère les données pour une clé donnée.
* [GET /map/maps](/api-reference/map/get-data-for-a-key) : cet endpoint récupère les données pour plusieurs clés.
* [POST /map/maps](/api-reference/map/update-data-for-several-keys) : cet endpoint publie des données pour plusieurs clés.
## Authentification et limitation de débit
### Authentification
La Data API utilise le même flux d'authentification que l'[Automation API](../automation-api-rest/get-started/get-started#authentification), en utilisant des JSON Web Tokens.
Maintenez la sécurité et protégez vos identifiants d'API en utilisant l'authentification pour des types de requêtes spécifiques :
* **Sources côté serveur** : pour les requêtes provenant de vos serveurs, Kameleoon recommande fortement l'authentification, qui augmente les [limites de débit](#limites-de-débit). Authentifiez-vous lorsque vous utilisez des SDK côté serveur avec Feature Experimentation.
* **Sources côté client** : pour les requêtes provenant d'une application cliente, telle qu'un navigateur web, où les identifiants d'API pourraient être exposés, **ne vous authentifiez pas**. Kameleoon ne recommande pas cette configuration lors de l'utilisation de Kameleoon Web Experimentation.
Toute requête fournissant un token d'API avec un format incorrect, un token expiré ou une signature invalide entraîne une réponse HTTP 401 « Unauthorized ».
Pour en savoir plus sur le processus d'authentification, consultez la documentation [Flux d'authentification de l'Automation API](../automation-api-rest/get-started/get-started#authentification).
Par défaut, la Data API ne requiert pas d'authentification car elle prend en charge le moteur de web experimentation pour la récupération des données historiques. Si vous utilisez Feature Experimentation et les SDK côté serveur exclusivement, contactez le Customer Success Manager pour activer l'authentification sur des endpoints spécifiques. Kameleoon propose une configuration flexible pour sécuriser les endpoints et restreindre l'authentification aux requêtes GET ou POST.
### Limites de débit
La Data API applique des limites de débit en fonction de votre **nombre contractuel de visiteurs uniques mensuels (MUV)** et de **votre adresse IP**. Si votre application dépasse l'une de ces limites, l'API renvoie une réponse **HTTP 429 - « Too Many Requests »**.
Ces limites de débit permettent de garantir que le service Kameleoon reste performant et fiable pour tous les clients.
Pour les **sources côté serveur**, vous pouvez lever les limites basées sur l'IP en vous [authentifiant](#authentification).
| **Type de requête** | **Limites appliquées à toutes les requêtes** | **Limites supplémentaires appliquées uniquement aux requêtes non authentifiées** |
| ------------------------ | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| **Requêtes GET** | `((500,000 + nombre de MUV) / 500) * multiplier` requêtes par minute par compte client | `120` requêtes par minute par IP |
| **Autres méthodes HTTP** | `((500,000 + nombre de MUV) / 50) * multiplier` requêtes par minute par compte client (par méthode) | `1,200` requêtes par minute par IP (par méthode) |
La valeur de `multiplier` dépend de votre abonnement :
* `1` — Vous utilisez une seule solution, Web Experimentation ou Feature Experimentation
* `2` — Vous utilisez à la fois Web Experimentation et Feature Experimentation
Si vous avez besoin de limites de débit plus élevées pour votre cas d'usage, veuillez contacter votre Account Manager pour plus d'informations.
#### Ce qui génère des requêtes
Comprendre quelles opérations génèrent des requêtes GET et POST vous aide à estimer et à gérer votre consommation de limite de débit. La répartition ci-dessous s'applique principalement aux **technologies côté client** (engine.js, le SDK JavaScript et les SDK mobiles), où chaque appareil émet ses propres requêtes. Pour les requêtes POST de tracking, les SDK côté serveur sont plus efficaces à grande échelle car ils peuvent regrouper les données de plusieurs visiteurs en une seule requête ; les requêtes GET ciblent toujours un seul visiteur.
**Votre application ne déclenche des requêtes GET** que lorsqu'elle appelle explicitement l'une des opérations suivantes. Le SDK et le moteur n'effectuent aucune interrogation automatique :
* **Récupérations de données visiteur** : `getRemoteVisitorData()` (SDK) ou `performRemoteSynchronization()` (engine.js) chargent les données visiteur distantes pour un visiteur spécifique à la demande.
* **Récupérations de données distantes et d'audiences warehouse** : `getVisitorWarehouseAudience()` (SDK) ou `retrieveDataFromRemoteSource()` (SDK et engine.js) chargent les données du warehouse de données ou les données de map distantes à la demande.
**Les requêtes POST** proviennent du mécanisme de tracking, qui regroupe les données visiteur avant de les envoyer :
* **Requêtes de tracking** : l'appel POST récurrent principal. Le SDK ou le moteur regroupe les données visiteur en attente et les envoie au plus une fois par intervalle de tracking, uniquement lorsqu'il y a des données en attente. L'intervalle par défaut est de 1 seconde. Dans les SDK, vous pouvez configurer l'intervalle entre 1 et 5 secondes à l'aide de `trackingIntervalMillisecond` / `tracking_interval_millisecond` ; engine.js utilise un intervalle fixe de 500 millisecondes. Les conversions, les évaluations de feature flags trackées et les appels explicites à `flush()` mettent les données en file d'attente pour le prochain intervalle, ou les envoient immédiatement si vous déclenchez un flush instantané.
* **Tracking d'activité** : un mécanisme secondaire qui contribue les données d'activité visiteur (clics, défilements et mouvements de souris) dans le prochain envoi de tracking. Le SDK ne collecte les données d'activité que lorsque l'utilisateur est actif sur l'onglet actif. L'intervalle par défaut est de 60 secondes. Dans les SDK, vous pouvez configurer l'intervalle à l'aide de `activityTrackingIntervalMillisecond` / `activity_tracking_interval_millisecond` ; engine.js utilise un intervalle fixe de 60 secondes.
Pour les **SDK mobiles** : le tracking périodique se met automatiquement en pause lorsque l'application passe en arrière-plan. Un flush immédiat explicite peut toujours envoyer les données en attente quel que soit l'état de l'application.
Pour le **SDK JavaScript** : la requête de tracking n'est envoyée que lorsque le visiteur a véritablement interagi avec la page (via un mouvement de souris ou un défilement) depuis le dernier tick de l'intervalle, ce qui empêche les onglets masqués ou en arrière-plan de gonfler le nombre de visites. Pour continuer à envoyer des données lorsque la page n'est pas active, appelez explicitement `flush({instant: true})`. Lorsque le moteur Kameleoon (`window.Kameleoon`) est également présent sur la page, le SDK empêche le double comptage du tracking d'activité.
#### Limites au niveau du compte
Les limites de débit s'appliquent à l'ensemble de votre compte client, et non à des projets individuels. Si un projet génère un nombre excessif de requêtes (par exemple parce qu'une implémentation défectueuse crée une boucle qui envoie des événements de données personnalisées de manière répétée), ce projet consomme la limite partagée du compte et peut provoquer des erreurs HTTP 429 dans tous vos autres projets.
#### Diagnostic d'un volume de requêtes excessif
Utilisez la page [Live events](/user-manual/experiment-analytics/analyze-results/data-and-metrics/live-events) (**Insights > Live events**) pour identifier le projet qui génère un trafic inattendu :
1. **Vérifier le volume d'événements par projet** : Sélectionnez chaque projet tour à tour et examinez le nombre d'événements sur la dernière heure ou les dernières 24 heures. Un projet générant beaucoup plus d'événements que ne le justifie son volume de visiteurs (par exemple, des dizaines de millions d'événements pour un contrat de 100 000 MUV) est probablement la source du problème.
2. **Filtrer par type d'événement** : Une fois le projet suspect identifié, filtrez les événements par type. Les événements de données personnalisées sont la cause la plus fréquente d'un volume inattendu. Une implémentation mal configurée peut créer une boucle qui envoie la même variable de données personnalisées, ou toutes les variables de données personnalisées, à chaque chargement de page, produisant un grand nombre d'événements en peu de temps.
#### Vérifier votre nombre de requêtes
Utilisez l'endpoint `GET /data-api-requests/stats` de l'Automation API pour voir exactement d'où provient votre volume de requêtes vers la Data API. Cet endpoint renvoie le nombre de requêtes envoyées à la Data API pour un site donné, ventilé par jour, méthode HTTP, chemin et code de statut, afin que vous puissiez identifier quelle intégration ou quel endpoint génère votre trafic avant qu'il n'approche de votre limite de débit.
Envoyez la requête avec trois paramètres de requête obligatoires :
| **Paramètre** | **Type** | **Description** |
| ------------- | -------- | ------------------------------------------------------------------------- |
| `siteCode` | string | Le sitecode Kameleoon. |
| `from` | date | Le début de la plage de dates, au format ISO 8601 (`YYYY-MM-DD`). Inclus. |
| `to` | date | La fin de la plage de dates, au format ISO 8601 (`YYYY-MM-DD`). Inclus. |
L'intervalle entre `from` et `to` ne peut pas dépasser 7 jours.
Authentifiez-vous avec un jeton bearer OAuth 2.0, en suivant le même [flux d'authentification de l'Automation API](../automation-api-rest/get-started/get-started#authentification) que celui utilisé pour les autres appels de l'Automation API :
```bash curl theme={null}
curl -H "Authorization: Bearer " \
-H "Content-Type: application/json" \
"https://api.kameleoon.com/data-api-requests/stats?siteCode=&from=2026-07-17&to=2026-07-23"
```
Exécutez cette vérification chaque fois que la page [Live events](/user-manual/experiment-analytics/analyze-results/data-and-metrics/live-events) affiche un trafic inattendu, pour confirmer quelles méthodes HTTP, quels chemins et quels codes de statut composent votre volume de requêtes.