Bonjour,
Comme indiqué précédemment, j’ai travaillé sur un outil en ligne de commande pour accéder à votre compte Finary.
Il permet notamment d’importer un fichier CSV pour ajouter/mettre à jour des cryptos ou des valeurs dans des comptes d’investissement. Il permet aussi de récupérer les lignes des différentes catégories en JSON brut pour le moment.
Vous pouvez trouver l’outil sur github.com ici. Il est sous licence libre.
Un exemple. Afficher le patrimoine brut.
python -m finary_api dashboard gross all | jq '.result["total"]["amount"]'
J’ai commencé à utiliser ton github finary. Je souhaiterais pouvoir mettre à jour les « autres actifs » de mon patrimoine (pour faire le suivi de mes actifs de crowdlending). J’ai l’impression que ce n’est pas supporté dans ton code. J’ai cru comprendre que l’API Finary n’était pas encore documentée. Aurais-tu un point d’entrée pour connaître la liste des requêtes HTTP supportées ? Ou alors sais-tu s’il est possible de lister dynamiquement les endpoints (avec Swagger par exemple que je n’ai encore jamais utilisé) ?
Salut, merci pour ton retour.
Je n’ai pas trouvé de endpoint pour lister les requêtes supportées. J’ai juste regardé ce qui passe entre l’interface web et l’API.
L’API est « privée » et non documentée. Elle peut changer à tout moment et rendre l’outil inutilisable
Je crée une issue sur github pour l’ajout de « autres » pour en discuter.
J’ai rajouté le support en lecture pour les prêts, les SCPIs, l’immobilier, la distribution de cryptos, les blockchains et les SCPIs supportées, et les insights + frais pour les finary +.
Great. If we want a client in several languages, it could be smart to describe the API in an openapi document and generate the clients ?
If you are OK with python, then your contributions are welcome !
What are your end goals ?
Mdr je ne sais même pas pourquoi je répondais pas en français. L’openapi semble être une bonne idée, j’ai à peu près les mêmes ambitions que toi je suppose. Je voulais juste à la base extraire mes assets pour fournir un PDF aux banques et je me suis laissé emporter. Concernant python c’est clairement pas ma tasse de thé par contre ^^
De mon côté j’avance tranquillement sur la version Ruby du wrapper de l’API (repo privé encore) et je m’attelle ensuite à un outil pour rajouter quelques fonctionnalités (top composants ETF & import Anaxago seront mes 2 premiers sujets).
Un peu dommage qu’on puisse pas collaborer à cause d’une incompatibilité de language. La tour de babel existe encore. J’ai déjà fait deux trois trucs en Rust et en Ruby mais je suis moins fluent qu’en Python… J’essaie de faire un début de OpenAPI (j’ai jamais fait) et de le mettre sur github pour qu’on puisse voir si on en fait quelque chose.
Un point important, je vois que tous les deux vous avez mappé le JSON dans des objets. Ici en rust. J’ai choisi de ne pas le faire et de faire craché du JSON à la ligne de commande pour ne pas à avoir à suivre les évolutions permanentes de l’API de Finary en terme de sortie. J’imagine que la génération de code via OpenAPI risque de changer ceci.
@julien il n’y aurait pas un fichier swagger ou openapi qui existe déjà et que vous seriez prêt à partager par hasard
L’idée de l’openapi est bonne mais je pense pas qu’avoir une lib dans plusieurs langages soit un problème, en effet moi j’ai plus tourné ça sous forme de lib que de cli ou réel tool pour permettre à d’autres potentiels devs de faire quelque chose. J’ai pris l’option de typé l’api même si c’est plus contraignant mais au moins si ça run sans erreurs c’est qu’on a bien accès a toutes ces infos
Un point important, je vois que tous les deux vous avez mappé le JSON dans des objets. Ici en rust . J’ai choisi de ne pas le faire et de faire craché du JSON à la ligne de commande pour ne pas à avoir à suivre les évolutions permanentes de l’API de Finary en terme de sortie.
C’est une bonne remarque, je me suis posé la même question. De mon côté la classe correspondant au client HTTP est compatible avec les évolutions de l’API en termes de paramètres d’entrées et de sorties, donc aucun soucis là dessus (ca prend un hash de paramètres en entrée et sort un hash en sortie).
Par contre sur les classes métier Ruby, là oui l’objectif c’est d’avoir un vrai mapping pour permettre:
de faire des traitements spécifiques : typiquement arrondir certaines valeurs pour éviter de renvoyer 10 décimales à l’utilisateur / rajouter des méthodes pour certains calculs qui sont fait aujourd’hui uniquement par l’UI de Finary
d’offrir un niveau d’abstration, du type :
u = User.new('me')
u.securities.each do |s|
puts "#{s.security.symbol}: #{s.current_value.to_i}"
end
# displays "DSY : 1230"
Un peu dommage qu’on puisse pas collaborer à cause d’une incompatibilité de language. La tour de babel existe encore. J’ai déjà fait deux trois trucs en Rust et en Ruby mais je suis moins fluent qu’en Python…
Je suis bien d’accord avec toi, c’est compliqué de ne pas bosser dans notre language préféré et frustrant de ne pas pouvoir collaborer d’un point de vue language. Après il n’y a pas que le language, il y a plusieurs sujets de discussions d’architecture et de philosophie sur lesquels on pourra collaborer. Typiquement sur l’intégration Crowfunding, très curieux d’avoir une discussion avec vous sur la meilleure manière de le faire (intégrer hellocrowdfunding VS anaxago directement, etc.).
Typiquement c’est le genre de décision que je laisserai à l’équipe de Finary. Ils sont en discussion avec Anaxago pour un accès API et Anaxago est une des intégrations potentielles dans les 3 mois d’après la roadmap.
Ce qui montre l’intérêt du coup d’avoir plusieurs initiatives Open Source.
Le crowlending est prévue dans la roadmap de 6 à 9 mois depuis au moins 9 mois. Je n’ai personnellement aucune visibilité sur la réeelle date de sortie.
Comme c’est une partie non négligeable de mon patrimoine (15%), je vais avancer de mon côté sur une solution pragmatique : j’ai juste besoin d’avoir un moyen de synchroniser automatiquement mes 20+ projets Anaxago automatiquement une fois par mois avec les bons montants en prenant en compte les entrées/sorties de capital, ce que je peux faire via leur API graphQL).
Les impatients comme moi pourront comme ça avoir un outil leur permettent de le faire, en attendant d’avoir l’intégration native dans Finary que j’ai hâte de découvrir.
L’outil supporte maintenant l’authentification à deux facteurs (2FA), soit en passant le code d’authentification en paramètre de signin, soit si le code n’est pas fourni mais que 2FA est activée par l’utilisateur, le programme demande un code 2FA avant de poursuivre.
Sauf erreur de ma part, les transactions d’un compte courant ne sont pas visibles sur finary, et donc pas accessible dans l’API, et donc pas accessible via cet outil. Je me trompe ?
