Données Supra. Conçues pour l’intégration.

Accès commercial, documentation publique

La documentation Supra Core et la spécification OpenAPI sont publiques. Le service API est commercial et authentifié : chaque requête, y compris health, exige une clé API valide liée à un accès activé. Les offres disponibles, usages autorisés et conditions commerciales sont convenus séparément avec TCP Labs.

Utilisez le contrat public pour évaluer une intégration avant de demander l'accès. Le service est en lecture seule : il n'exécute pas d'échanges, ne signe pas de transactions, ne gère pas de portefeuilles et ne conserve pas d'actifs. Les bots doivent se limiter au suivi, à l'analyse et aux notifications.

Endpoints en lecture seule

Toutes les routes ci-dessous utilisent GET. Les listes d'événements FA et Legacy restent séparées ; les événements farm sont inclus dans les réponses d'événements de liquidité.

Conservez les prix et montants DECIMAL sous forme de chaînes exactes. Préservez les valeurs indisponibles et leurs motifs ; une réponse vide réussie n'est pas une erreur. Pour les affichages en USD, utilisez change_24h_usd_pct, et non la variation distincte exprimée dans la paire. Les points reportés ne rendent pas un marché inactif récent. Consultez le contrat de chaque endpoint pour les filtres, la pagination et les champs de preuve.

Authentification et première requête

Envoyez soit X-API-Key ou Authorization: Bearer. Conservez les clés du service dans votre backend, pas dans un bundle public du navigateur ni dans une URL. Pour l'accès authentifié par base de données, la clé, le client et l'offre doivent être activés ; l'expiration et les IP autorisées sont vérifiées.

L'exemple lit l'URL de base et la clé du service depuis votre environnement local. TCP Labs fournit l'adresse du service avec les détails d'accès. Cette page ne contacte pas l'API.

curl --get "${SUPRA_CORE_API_BASE_URL}/api/v1/market/current" \
  --header "X-API-Key: ${SUPRA_CORE_API_KEY}" \
  --data-urlencode "network=mainnet" \
  --data-urlencode "limit=20" \
  --data-urlencode "offset=0"

Les réponses réussies utilisent ok: true avec data et meta. Les erreurs utilisent ok: false avec un objet error contenant code et message. Les paramètres invalides renvoient 400, l'authentification refusée 401, une route inconnue 404 et une méthode non prise en charge 405.

Limites et requêtes fiables

Les limites sont attribuées à votre offre activée. Le limiteur compte les requêtes par fenêtres fixes d'une minute et d'un jour UTC pour chaque clé API et IP cliente. Tout dépassement renvoie 429 avec RATE_LIMITED. Les tentatives limitées sont comptées ; une nouvelle fenêtre démarre un nouveau compteur. Il s'agit de quotas par fenêtre, pas d'un délai imposé entre les requêtes.

burst_limit est informatif dans le contrat actuel : ce n'est ni une limite appliquée aux requêtes simultanées ni un compteur burst distinct. N'en déduisez pas de capacité supplémentaire. L'en-tête Retry-After n'est pas garanti.

Lire la documentation API complète pour tous les paramètres, exemples et contrats de réponse.

En cas de 429, réduisez la charge et réessayez plus tard avec une attente progressive bornée et aléatoire. Mettez les lectures partagées en cache et coordonnez les workers. Ne réessayez pas des paramètres invalides ou clés refusées sans correction. La pagination limite les lignes, pas les quotas : les listes de marchés et événements sont limitées à 500 lignes par page ; les routes de bougies et graphiques ont leurs propres limites documentées.