Skip to main content
Nouveau dans Événements analysés ? Lisez d’abord le modèle mental des flux analysés — Événements analysés renvoie les mêmes instructions décodées sur REST et GraphQL.

Démarrage rapide

1

Obtenez l'accès

Les événements analysés sont en version bêta ouverte, disponibles sur les forfaits payants. Obtenez votre clé API sur le tableau de bord Helius et envoyez des requêtes à https://mainnet.helius-rpc.com.Authentifiez-vous avec la clé API de votre projet, passée en tant que paramètre de requête api-key.
2

Analyser une transaction

Passez les signatures dans le champ de corps transactions de POST /v1/parsed-events/transactions :
3

Lire le résultat

La réponse contient un résultat par signature demandée, dans l’ordre d’entrée. Chaque résultat inclut signature, parserStatus, et soit parsed ou parserError :
L’exemple est réduit à deux instructions : un transfert de jeton décodé à l’intérieur de l’itinéraire et une instruction AMM dont le catalogue connaît le programme mais ne peut pas le décoder, ce qui laisse instructionName comme null tandis que rawData et rawAccounts restent disponibles. Voir Réponse analysée pour chaque champ et un exemple de réponse complet.
4

Récupérer l'historique des adresses

POST /v1/parsed-events/transaction-history renvoie les mêmes résultats analysés que ci-dessus, pour chaque transaction qui a touché une adresse, du plus récent au plus ancien par défaut :
5

Paginer

Les réponses d’historique enveloppent les résultats dans un objet page. Passez paginationToken dans la requête suivante pour continuer. Si paginationToken est manquant, le service a atteint la fin de la plage de pages disponible.

Guides

Récupérer les Mint de Pump.fun

Feuilletez chaque jeton qu’un portefeuille a déployé sur Pump.fun.

Requête avec GraphQL

Sélectionnez exactement les champs analysés dont votre application a besoin.

Migrer depuis les transactions améliorées

Mappage des points de terminaison, paramètres, et réponses de l’API héritée.

Référence REST

Les deux méthodes REST acceptent un corps JSON via POST sous /v1/parsed-events/ à https://mainnet.helius-rpc.com, authentifié avec le paramètre de requête api-key. Les corps de requête rejettent les champs inconnus, donc les fautes de frappe échouent bruyamment au lieu d’être silencieusement ignorées. Les requêtes GraphQL vont à POST /v1/parsed-events/graphql.

Analyser les transactions

POST /v1/parsed-events/transactions récupère les transactions complètes de Solana par signature, les décode avec le même décodeur d’instructions basé sur IDL qui alimente les flux analysés et renvoie un TransactionResult par signature demandée. La même méthode est disponible en GraphQL sous transactions. L’ordre des réponses correspond à l’ordre d’entrée, y compris les signatures en double. Les transactions manquantes et les échecs de l’analyseur par élément sont retournés en tant que résultats de niveau élément parserStatus: "ERROR" :

Corps de requête

string[]
requis
Signatures de transactions à analyser. La taille maximale du lot est de 100.
string
défaut:"confirmed"
Niveau d’engagement utilisé lors de la récupération des transactions.
  • confirmed
  • finalized
boolean
défaut:"false"
Lorsque true, incluez la charge utile brute de la transaction Solana comme rawTransaction sur chaque résultat.

Remarques

  • processed l’engagement n’est pas pris en charge.
  • rawTransaction est omis sauf si includeRawTransaction est true.
  • Les échecs d’exécution des transactions peuvent encore être analysés. Dans ce cas, parsed.transactionStatus est ERROR, et l’erreur de transaction est exposée sur parsed.error lorsqu’elle est disponible.
  • Les erreurs de validation au niveau des requêtes renvoient une réponse d’erreur au lieu de résultats au niveau des éléments.

Historique des transactions analysées

POST /v1/parsed-events/transaction-history renvoie l’historique des transactions analysées pour une adresse. Il prend en charge la pagination, les limites de signature, les limites de slot, les limites de temps de bloc, l’ordre de tri et les transactions brutes facultatives. La même méthode est disponible en GraphQL sous transactionsByAddress. Contrairement au point de terminaison d’adresse des transactions améliorées héritées, les paramètres de requête sont envoyés dans un corps JSON plutôt que par des paramètres de chaîne de requête.

Corps de requête

string
requis
Adresse dont l’historique des transactions doit être récupéré.
number
défaut:"100"
Nombre de transactions à retourner. Doit être compris entre 1 et 100.
string
Retourner les transactions avant cette signature.
string
Retourner les transactions après cette signature.
string
Curseur retourné par la réponse précédente.
string
défaut:"desc"
Ordre de tri pour les transactions retournées.
  • asc
  • desc
string
défaut:"confirmed"
Niveau d’engagement utilisé pour la récupération de l’historique.
  • confirmed
  • finalized
boolean
défaut:"false"
Lorsque true, incluez la charge utile brute de la transaction Solana comme rawTransaction sur chaque résultat.
object
Limites de comparaison de slot. Chaque limite est facultative : gt, gte, lt, lte.
object
Limites de comparaison du temps de bloc en secondes Unix. Chaque limite est facultative : gt, gte, lt, lte.

Pagination

Les réponses ont cette forme. Chaque élément data utilise le même format TransactionResult renvoyé par Analyser les transactions :
Passez paginationToken dans la requête suivante pour continuer. Si paginationToken est manquant, le service a atteint la fin de la plage de pages disponible.