L'API Eulerian utilise un token Bearer transmis dans le header HTTP Authorization.
Authorization: Bearer <votre_token_api>
- Ne jamais embarquer le token en dur dans le code source. Utiliser une variable d'environnement ou un coffre-fort de secrets (Vault, AWS Secrets Manager, etc.).
- Restreindre les tokens aux permissions strictement nécessaires (principe du moindre privilège).
- Ne pas loguer les headers d'autorisation dans les fichiers de log applicatifs.
Toutes les requêtes doivent transiter par HTTPS.
https://<votre_domaine_eulerian>/ea/v2/<endpoint>
Le domaine est propre à votre compte Eulerian (ex. dem.api.eulerian.com).
- Respecter les limites de débit imposées par Eulerian (consulter la documentation de votre contrat).
- Implémenter un mécanisme d'exponential backoff en cas de réponse
429 Too Many Requests. - Ne pas paralléliser abusivement les appels : préférer des files de traitement ordonnées.
- Pour les requêtes de création de job, utiliser un identifiant métier (
jobrun_id côté client) pour éviter les doublons en cas de retry. - Vérifier l'existence d'un job similaire avant d'en créer un nouveau.
Le est le mécanisme principal pour extraire des volumes importants de données analytiques depuis la plateforme Eulerian. Contrairement aux requêtes synchrones (limitées à de petits volumes), le Batch fonctionne de manière :
Vous soumettez une requête de rapport → Eulerian crée un et vous retourne un jobrun_id.
Vous interrogez périodiquement le statut du job ().
Une fois le job terminé (DONE), vous téléchargez le fichier de résultats.
Extraction de données sur plus de 7 jours
Volume > 10 000 lignes attendues
Traitements planifiés / ETL nightly
Tableaux de bord temps réel (< 1 000 lignes)
Tests / exploration ad hoc
[SUBMIT] → PENDING → RUNNING → DONE
Job en file d'attente, pas encore traité
Traitement en cours côté Eulerian
Rapport prêt au téléchargement
Erreur lors du traitement (voir le champ error)
Le fichier de résultats n'a pas été téléchargé dans les délais
Les fichiers générés par Eulerian sont disponibles pendant une durée limitée (généralement 24 à 72 heures). Télécharger et archiver les résultats dès que le statut est DONE.
GET /ea/v2/report/batch/status.json?jobrun-id={jobrun_id}
Ne jamais effectuer un polling trop agressif : cela consomme inutilement votre quota d'appels API.
Définir un timeout global (ex. 4 heures). Au-delà, considérer le job comme en échec et alerter.
- Stocker le
jobrun_id de façon persistante (base de données, fichier) pour pouvoir reprendre le polling après un redémarrage de votre application. - Ne pas relancer un nouveau job si un job identique est déjà en cours (
PENDING ou RUNNING).
TANT QUE timeout non atteint :
statut = GET /batch/status.json?jobrun-id{jobrun_id}
SI statut == DONE → télécharger résultat → FIN
SI statut == FAILED → logger erreur → FIN
SI statut == EXPIRED → relancer job → FIN
ATTENDRE intervalle_adaptatif()
SINON → alerter équipe ops
GET /ea/v2/report/batch/download.json?jobrun-id={jobrun_id}
La réponse contient soit le fichier directement en streaming, soit une URL de téléchargement temporaire.
- le téléchargement plutôt que de charger le fichier entier en mémoire (les fichiers peuvent atteindre plusieurs centaines de Mo).
- Archiver le fichier brut avant tout traitement (principe de l'idempotence du traitement).
- Toujours spécifier l'encodage
UTF-8 à l'ouverture du fichier. - Gérer les lignes d'en-tête dynamiquement (les colonnes peuvent évoluer).
- Valider le nombre de colonnes de chaque ligne avant insertion en base.
- Gérer les valeurs nulles / chaînes vides explicitement (ne pas les confondre avec
0).
Pour des fichiers > 100 Mo :
- Traiter ligne par ligne en streaming (ne jamais tout charger en RAM).
- Insérer en base par (bulk insert).
- Implémenter une reprise sur erreur avec marquage de la dernière ligne traitée.
Logger la réponse, corriger les paramètres
Renouveler le token, alerter
Permissions insuffisantes
Vérifier les droits du token
Le job a expiré ou l'ID est erroné
Backoff exponentiel (min. 60s)
Retry après délai, contacter le support si persistant
Retry avec backoff, surveiller le statut Eulerian
Tentative 2 : +5 secondes
Tentative 3 : +15 secondes
Tentative 4 : +60 secondes
Tentative 5 : +300 secondes
Au-delà : alerter et abandonner
Ne jamais retry sur les erreurs 400, 401, 403 (erreurs client — corriger d'abord le problème).
- Logger systématiquement : timestamp, endpoint appelé, code HTTP reçu,
job_id, durée de la requête. - Ne jamais logger le token d'API ni les données personnelles des utilisateurs finaux.
- Conserver les logs d'erreur au moins 30 jours pour faciliter le débogage.