Je développe et utilise mes propres outils pour certains tracking - ex : stablecoins on-chain, positions RWA.
Ces outils sont accessibles en ligne et peuvent disposer d’API.
Comme Finary ne souhaite pas intégrer certaines plateformes, pourquoi ne pas avoir une option « + Add Assets » > « Custom API » où l’on entrerait simplement une URL d’une API externe.
Cette API externe serait chargée de retourner un résultat attendu par Finary.
Ex :
GET http://mycustomfinaryadapter/api/finary/<secret_id>
Le format n’aurait pas besoin d’être compliqué. Juste assez pour afficher l’information sur le Dashboard de Finary.
Cela permettrait à l’ensemble de la communauté de développer leurs propres « adaptateurs » qui pourraient se brancher et se débrancher directement depuis la plateforme.
Bon pour les développeurs Finary, bon pour la commu
Je suis également développeur, et j’allais ouvrir un post exactement dans ce sens!
Il faut avoir en tête que Finary ne pourra jamais couvrir toutes les situations.
Finary est un agrégateur de données. Alors permettez nous de vous fournir des données!
Il y a deux possibilités:
Soit ce sont les sources de données externes qui poussent à Finary les données à intervalles réguliers. Et donc c’est une API Finary à développer (mais de ce que j’ai lu dans le forum c’est un serpent de mer ce sujet… Ce qui est dommage car ça ouvrirait plein de cas d’usage que Finary ne pourrait pas couvrir seule.)
Soit c’est Finary qui se synchronise quand elle le souhaite. Ce qui donne techniquement plus de latitude à Finary. Et c’est le modèle codé aujourd’hui pour tout le reste. Il s’agit donc de développer un connecteur « API Externe ». En revanche c’est plus « lourd » pour le gestionnaire de la source externe car ça implique un serveur connecté 24h/7j alors que la première solution permettant d’imaginer des programmes chargé uniquement pour le temps d’une synchronisation).
En réalité l’idéal serait d’avoir les deux qui sont très complémentaire. Mais si déjà on peut avoir un connecteur « API Externe » avec les échanges de données, gestion de la sécurité de votre choix. Ca serait déjà un sacré pas en avant. D’autant que des connecteurs vous en avez déjà développeur pleins, vous avez de l’expérience dessus. Repartir du connecteur que vous jugez techniquement meilleur, pour faire un draft de l’échange de données, ça ne devrait pas être compliquer/chronographe pour Finary.
Exemple de situation que cela peut couvrir, qui n’est pas couverte aujourd’hui par Finary: Veracash.
Partons du principe que:
Un développeur met sur Github un service qui « fait le pont » entre Veracash et Finary, appellons le VeraBridge. Et qui explique à n’importe qui comment l’installeur sur son propre serveur (dans un premier temps, on peut imaginer par la suite un service disponible à tous les usagers de Finary, sans avoir à gérer la partie technique: et c’est pour ça qu’il faut le code avec une sécurité adaptée).
Finary propose le connecteur API Externe
L’utilisateur à configurer le connecteur API externe
Malheureusement Veracash ne propose pas d’API, et le triptyque pseudo/login/mot de passe Veracash ne suffisent pas, car le MFA empêche tout automatisation. Cependant, l’utilisateur peut extraire l’historique de son compte sous forme de fichiers xlsx, et charger ces fichiers dans VeraBridge et faire cela une fois par mois.
Les données de Veracash seront mit à jour beaucoup plus simplement que ce qu’il faut faire aujourd’hui pour contourner le problème.
Aujourd’hui, il n’y a pas Vancelian, mais on pourrait imaginer la même chose… Bref vous comprenez l’idée.
Ce n’est clairement pas à Finary de supporter l’interprétation des fichiers d’historique fournit par Veracash (et ce n’est pas à Veracash de supporter l’intégration de ses données dans Finary)… Vous êtes agrégateur de données, alors laissez nous vous fournir des données…
Sujet déjà évoqué. Svp faites une petite recherches avant de créer un nouveau post. Surtout dans la catégorie Nouvelles Fonctionnalités. @GauthierDB Possible de merge la conv svp ?
