Search Lite et Summary Lite : de nouveaux endpoints pour les données essentielles sur les actifs

Deux nouveaux endpoints sont disponibles dans l’API FinImpulse : Search Lite et Summary Lite, qui s’ajoutent aux endpoints Search et Summary existants. Tous deux renvoient un ensemble de champs réduit et fixe par rapport à leurs équivalents standard, et permettent de restreindre davantage la réponse aux seuls champs dont une requête donnée a besoin.

Cet article explique le fonctionnement de ces deux endpoints, en quoi ils se comparent à Search et Summary, et dans quels cas chacun s’intègre le mieux dans une intégration type.

Search vs. Search Lite & Summary vs. Summary Lite

Les endpoints Search et Summary existants sont vastes et exhaustifs.

• Search renvoie plus de 65 champs pour les requêtes multi-actifs, couvrant la classification, les détails des places de cotation, les prix, les indicateurs techniques, les dividendes, la valeur de marché, la rentabilité et les données de croissance.
• Summary renvoie plus de 235 champs pour un symbole unique, couvrant l’identité, l’adresse, la classification sectorielle et industrielle, les indicateurs de risque de gouvernance, les prix, la valorisation, l’actionnariat, la couverture des analystes et des champs propres aux fonds.

Search Lite et Summary Lite sont des alternatives plus légères à ces deux endpoints : chacun renvoie un ensemble de champs réduit et fixe, coûte moins cher (voir la tarification de l’API) et permet de personnaliser davantage la réponse grâce à un paramètre select_identifiers qui détermine lesquels des champs disponibles sont renvoyés.

Il est important de noter que les endpoints standard et Lite sont distincts et indépendants en termes d’implémentation : chacun possède son propre ensemble de champs fixe, son propre schéma de réponse et sa propre tarification. Les endpoints Lite ne renvoient pas un sous-ensemble de tous les champs disponibles dans Search ou Summary — chaque endpoint Lite possède son propre ensemble de champs, plus réduit et fixe.

Endpoint Search Lite

Search Lite renvoie des résultats de recherche multi-actifs couvrant les actions, les ETF et les fonds communs de placement. Il utilise les mêmes paramètres de recherche et de filtrage que l’endpoint Search standard : recherche en texte libre, filtrage par type de cotation, listes de symboles, expressions de filtre, tri et pagination. La réponse contient 26 champs : données d’identification, prix actuels et indicateurs de performance couramment utilisés.

Search Lite convient donc aux interfaces de recherche et aux composants d’autocomplétion, lorsqu’une requête doit renvoyer rapidement un grand nombre d’actifs correspondants et que seules les données essentielles d’identification et de prix sont nécessaires pour afficher les résultats. C’est aussi un choix par défaut raisonnable pour toute intégration qui effectue des requêtes de recherche fréquentes et n’a pas besoin des données plus étendues — fondamentaux, indicateurs techniques ou valorisation — disponibles via l’endpoint Search standard.

Endpoint Summary Lite

Summary Lite récupère un instantané de données ciblé pour un symbole d’actif unique, à partir du schéma unifié — les champs qui ne s’appliquent pas à un type d’actif donné sont renvoyés avec la valeur null ou sous forme de chaîne vide (“”). L’endpoint prend un paramètre unique et obligatoire, symbol, et la réponse comprend 27 champs couvrant l’identification, les prix actuels, les données de dividendes et un petit ensemble d’indicateurs de marché et de valorisation.

Summary Lite convient parfaitement aux vues compactes de détail d’actif, aux widgets de tableau de bord ou à tout workflow nécessitant un petit ensemble prévisible de champs de prix et de valorisation pour un symbole unique, sans récupérer la réponse Summary complète. C’est un choix raisonnable chaque fois qu’une intégration n’affiche que quelques indicateurs par actif et ne nécessite ni chiffres financiers clés, ni données d’actionnariat, ni couverture des analystes, ni historique de performance des fonds.

Paramètre Select Identifiers

Search Lite et Summary Lite acceptent toutes deux un paramètre select_identifiers facultatif. Ce paramètre accepte une liste de noms de champs et réduit la réponse à ces seuls champs.

Exemple de code — un select_identifiers pour Summary Lite :

  "select_identifiers": [
            "average_volume",
            "average_volume_10days",
            "market_cap",
            "fifty_two_week_low",
            "fifty_two_week_high",
            "current_price",
            "current_price_usd",
            "regular_market_price_usd",
            "pre_market_price_usd",
            "post_market_price_usd",
            "valuation_measures_forward_pe_ratio",
            "valuation_measures_pb_ratio",
            "valuation_measures_pe_ratio",
            "valuation_measures_ps_ratio"
    ]

La sélection est limitée aux champs disponibles pour chaque endpoint. La liste complète des champs disponibles pour Search Lite et Summary Lite figure dans leur documentation respective.

Voici quelques points importants à garder à l’esprit concernant le comportement du paramètre :

• Si le paramètre n’est pas fourni ou est défini sur null, l’ensemble complet des champs Lite est renvoyé.
• Les champs symbol et logo sont toujours inclus dans la réponse, quels que soient les champs spécifiés.

Le paramètre select_identifiers devient donc particulièrement précieux à grande échelle. Pour des intégrations telles que les exports en masse, les tableaux de bord de suivi ou les extractions de données planifiées qui ne nécessitent que quelques champs spécifiques par actif, il évite la surcharge que représente la récupération de la réponse Lite complète à chaque requête.

L’essentiel

Les nouveaux endpoints Lite, associés au paramètre select_identifiers, offrent un meilleur contrôle sur la quantité de données renvoyées à chaque requête — et, par extension, sur la taille des réponses et les coûts à grande échelle.

Pour les équipes qui développent des interfaces de recherche, des vues détaillées compactes ou des extractions de données à fort volume, il devient plus facile d’aligner la réponse de l’API sur ce qu’une fonctionnalité affiche réellement, plutôt que de composer avec un payload fixe et plus large.