API Era
Points de terminaison, authentification, pagination et limites de l'API Era, avec des requêtes prêtes à copier.
Dernière mise à jour : 1 octobre 2026
Ces points de terminaison fonctionnent dès aujourd'hui, mais l'API continue d'évoluer, alors certains détails peuvent changer. Consulte la date de dernière mise à jour en haut de la page pour savoir quand elle a été révisée pour la dernière fois.
Démarrage rapide
Avant de commencer, il te faut un compte Era avec au moins une institution branchée — sans connexion, ces points de terminaison n'ont rien à retourner.
- 1
Connecte-toi à Era et branche une institution, si ce n'est pas déjà fait.
- 2
Ouvre tes clés d'API dans le tableau de bord et crée une clé. La plupart des portées sont cochées au départ ; celles qui peuvent déplacer de l'argent, passer des ordres de bourse, modifier ta facturation, supprimer tes documents ou créer d'autres clés ne le sont pas. Décoche celles dont tu n'as pas besoin. Pour lire, il faut banking:read, et pour modifier quoi que ce soit, banking:write. Tu choisis aussi une expiration ; il n'y a pas d'option « jamais ».
- 3
Copie la clé et conserve-la en lieu sûr, par exemple dans un gestionnaire de secrets. Elle ne s'affiche qu'une fois : si tu la perds, crée-en une nouvelle.
- 4
Envoie-la dans un en-tête avec ta requête.
curl "https://forge.era.app/api/banking/transactions?page=1&pageSize=20" \
-H "X-API-Key: fmk_your_key_here"{
"transactions": [ … ],
"pagination": {
"currentPage": 1,
"pageSize": 20,
"totalItems": 412,
"totalPages": 21
},
"historyWindowApplied": true,
"historyWindowFloorDate": "2026-06-28",
"historyWindowHiddenCount": 137,
"historyWindowEarliestDate": "2024-03-02",
"historyWindowDegraded": false
}Tu écris ton propre client ? Génère-le à partir du document OpenAPI à https://forge.era.app/api/openapi/public.json. Il décrit chaque point de terminaison de cette page — chaque champ, chaque statut et chaque sorte de filtre et d'action de règle — et c'est l'API elle-même qui le sert, donc il ne prend pas de retard.
Points de terminaison
Dix-sept points de terminaison : huit en lecture et neuf en écriture.
- GET
- GET/banking
/accounts /{accountId} /balance - GET/banking
/accounts /summary - GET/banking
/transactions - PUT/banking
/transactions /{id} - PUT/banking
/transactions /bulk - GET/banking
/categories - POST/banking
/categories - GET
- POST/banking
/tags - GET
- POST/banking
/rules - POST/banking
/rules /preview - PUT/banking
/rules /{ruleId} - POST/banking
/rules /{ruleId} /enable - POST/banking
/rules /{ruleId} /disable - DELETE/banking
/rules /{ruleId}
Authentification
Envoie ta clé de l'une de ces deux façons :
- En-tête
- X-API-Key: fmk_your_key_here
- Jeton bearer
- Authorization: Bearer fmk_your_key_here
Chaque requête est chiffrée avec TLS.
Les clés expirent, et tu choisis dans combien de temps à la création. Le maximum est de 90 jours sur le forfait gratuit et de 365 sur un forfait payant — il n'existe pas d'option « n'expire jamais », alors ce que tu bâtis là-dessus a besoin d'un plan pour faire tourner la clé avant qu'elle tombe.
En-têtes de réponse
Les en-têtes X-RateLimit-* indiquent ton budget quotidien, donc tu ne les verras que sur un forfait qui en publie un. Pour l'instant, c'est seulement le forfait gratuit. Même là, considère-les comme facultatifs : une réponse sans eux veut dire que le compte est inconnu, pas que quelque chose a mal tourné. Chaque 429 porte Retry-After.
- X-RateLimit-Limit
- Le budget quotidien de ton forfait. Envoyé uniquement sur les forfaits qui publient un budget quotidien, et jamais sur un 429 d'une autre limite.
- X-RateLimit-Remaining
- Ce qu'il reste de ton budget quotidien. Jamais en dessous de zéro. Envoyé uniquement sur les forfaits qui publient un budget quotidien, et jamais sur un 429 d'une autre limite.
- X-RateLimit-Reset
- Quand ton budget quotidien libère sa prochaine requête, une seule, en horodatage Unix en secondes. Ce n'est pas le moment où tout le budget se renouvelle : le budget roule, donc les requêtes reviennent une à une. Envoyé uniquement sur les forfaits qui publient un budget quotidien, et jamais sur un 429 d'une autre limite. Le plafond de rafale par minute n'a pas d'en-tête à lui. Voir Limites
- Retry-Afterseulement sur un 429
- Chaque 429 porte Retry-After : attends ce nombre de secondes, puis réessaie. Un 429 qui porte aussi les en-têtes X-RateLimit-* a été refusé par le budget quotidien du forfait gratuit. Un 429 sans eux a été refusé par une autre limite, comme le plafond de rafale par minute. Retry-After peut aller d'une seconde à 24 heures. Voir Limites
Erreurs
L'API renvoie ces codes de statut d'erreur :
- 400
Entrée invalide : un paramètre incorrect, une mise à jour groupée vide ou de plus de 100 éléments, une écriture qui définit et efface le même champ dans le même appel, ou une règle qui ne tient pas debout. Supprimer, activer ou désactiver une règle refuse aussi toute clé de requête qu'on n'accepte pas, et le 400 la nomme.
- 401
Pas de clé, ou une clé qui ne s'analyse pas. Envoie-la dans l'en-tête X-API-Key ou comme jeton bearer.
- 402
Un quota de forfait fait obstacle. Aujourd'hui, ça ne concerne que la création d'une catégorie ou d'une règle de motif. Attendre n'y change rien, mais un forfait supérieur, oui. Appeler trop vite, c'est un 429.
- 403
La clé ne porte pas la portée dont cet appel a besoin — ou, sur l'une des deux écritures de transactions, l'id appartient à quelqu'un d'autre ou n'existe pas. L'API ne distingue pas ces deux cas. Une règle de la bibliothèque d'Era répond 403 quand tu essaies de la supprimer, ou de changer son nom, sa description, sa priorité, ses dates ou son applicationScope. Changer ses filtres, ses actions ou son groupe donne plutôt un 400.
- 404
Quelque chose qui n'existe pas. L'endpoint de solde le renvoie sans corps pour un accountGroupKey qui ne désigne aucun compte, ou qui n'a même pas la forme d'une clé. Les endpoints de règles le renvoient pour une clé de règle qui n'est pas à toi. Les transactions ne renvoient jamais 404 — voir 403.
- 409
Autre chose a modifié la ligne pendant que tu écrivais — pour une règle, c'est une version qui n'est plus l'actuelle. Relis-la et renvoie ton écriture. Sur une règle, un 409 peut aussi vouloir dire que ses actions déclencheraient des règles en boucle ; change alors les actions.
- 429
Trop de requêtes. Tu as épuisé ton budget quotidien sur le forfait gratuit ou atteint une autre limite, comme le plafond de rafale par minute. Retry-After indique combien de temps attendre, d'une seconde à 24 heures, et, contrairement à un 402, attendre libère ta prochaine requête. Voir Limites pour les chiffres publiés et ce que dit un 429.
Formes d'erreur
La plupart des erreurs reviennent sous la même forme : statusCode, message et un objet errors qui nomme ce qui n'allait pas. Pas toutes : un 401, et le 404 de l'endpoint de solde, reviennent sans corps du tout, alors lis le statut avant de lire le corps.
{
"statusCode": 403,
"message": "One or more errors occurred!",
"errors": {
"generalErrors": ["Transaction does not belong to the authenticated user"]
}
}Erreurs courantes
Définir un champ et l'effacer dans la même écriture — 400.
Plus de 100 id dans une mise à jour groupée — 400, et rien n'est modifié. Moins d'un id donne le même résultat.
Une transaction qui n'est pas la tienne, ou qui n'existe pas — 403, jamais 404. La réponse ne te dit donc jamais si un id existe, seulement qu'il n'est pas à toi.
Autre chose a modifié la ligne en premier — 409.
Limites
Deux des endpoints documentés plafonnent ce que tu peux demander en un seul appel. Les autres non.
Pas de plafond par appel ne veut pas dire illimité. Les clés expirent toujours, les écritures ont toujours des limites de longueur de champ, la création d'une catégorie ou d'une règle de motif peut atteindre un quota de forfait, ton forfait peut toujours masquer l'historique ancien, et chaque appel compte dans les limites de débit de ton forfait, décrites plus bas.
Comptes, solde, résumé, les listes de catégories et de tags, la création d'une catégorie, la création d'un tag, l'écriture d'une seule transaction et chaque endpoint de règles n'ont aucun plafond de volume par appel. Tu reçois l'ensemble au complet, ou la seule ligne que tu as nommée — sauf l'aperçu d'une règle, qui compte les correspondances mais ne retourne qu'au plus 50 de leurs clés et 10 échantillons.
pageSize est plafonné à 100, jamais refusé. Demande-en plus et tu reçois 100 lignes avec un 200 — lis pagination.pageSize dans la réponse plutôt que de faire confiance à ce que tu as envoyé.
L'écriture groupée de transactions est plafonnée à 100 id, et contrairement à pageSize elle est refusée plutôt que plafonnée : envoie 101 et tu reçois un 400, rien ne change.
Les clés expirent selon un calendrier que tu choisis à la création — jusqu'à 90 jours sur le forfait gratuit, 365 sur un forfait payant. Il n'existe pas d'option sans expiration.
Ton forfait peut appliquer un plancher de fenêtre d'historique qui masque les transactions plus anciennes. La réponse des transactions porte les champs historyWindow qui indiquent si un plancher s'est appliqué et où il se situe.
Limites de débit
Era publie deux limites de débit. Chaque forfait a un plafond de rafale : une limite de requêtes sur toute minute glissante. Le forfait gratuit a en plus un budget quotidien : une limite de requêtes sur toute période glissante de 24 heures. Une requête cesse de compter dans le plafond de rafale une minute après que tu l'as faite, et dans le budget quotidien un jour après. Les forfaits payants n'ont pas de budget quotidien publié pour l'instant. Dépasse l'une ou l'autre, ou toute autre limite que l'API applique, et l'appel revient en 429.
Les limites appartiennent à ton compte, pas à une clé. Chaque clé REST que tu crées puise dans le même plafond de rafale et, sur le forfait gratuit, dans le même budget quotidien : une deuxième clé ne te donne donc pas plus d'appels. Les appels d'outils MCP sont comptés à part : les appels REST et les appels MCP n'entament jamais les limites des uns des autres.
| Forfait | Budget quotidien | Plafond de rafale |
|---|---|---|
| De base | 100 par jour | 10 par minute |
| Organize | Aucun | 30 par minute |
| Automate | Aucun | 60 par minute |
| Optimize | Aucun | 60 par minute |
| Operate | Aucun | 120 par minute |
Pour l'instant, les forfaits payants n'ont pas de budget quotidien publié.
Les forfaits payants fonctionnent aussi selon l'utilisation raisonnable : l'API est faite pour des scripts, des tableaux de bord et des intégrations sur tes propres données financières, à un volume qui convient à une personne.
Aucun en-tête n'indique le plafond de rafale, sur aucun forfait : règle donc ton rythme sur le tableau. Sur le forfait gratuit, X-RateLimit-Remaining peut être bien au-dessus de zéro juste avant qu'une rafale revienne en 429.
Ce que dit un 429
Quelle limite t'a refusé. Un 429 qui porte les en-têtes X-RateLimit-* vient du budget quotidien du forfait gratuit; un 429 sans eux, d'une autre limite, comme le plafond de rafale. Le corps est au format problem-details, et son champ detail indique quand ta prochaine requête se libère. Si c'est le budget quotidien ou le plafond de rafale qui t'a refusé, il nomme aussi cette limite, ce qu'elle permet et le forfait qui la relève ou la retire, ou que tu es déjà sur le plus élevé. Il est écrit pour des humains : lis les en-têtes plutôt que de l'analyser.
{
"type": "https://httpstatuses.com/429",
"title": "Too Many Requests",
"status": 429,
"detail": "You've used up your daily budget of 100 requests. Your next request frees up at 2026-09-16T09:00:00Z. The Organize plan removes it."
}Chaque 429 porte aussi Retry-After : un nombre entier de secondes, d'une seconde à 24 heures. L'attente du plafond de rafale est d'au plus une minute; le budget quotidien du forfait gratuit peut demander les 24 heures complètes. Un appel refusé ne compte dans aucune limite, mais ne réessaie pas trop tôt : attends la fin de Retry-After sur chaque 429. Avec le budget quotidien et le plafond de rafale, une tentative trop hâtive est refusée à son tour, et à la fin de l'attente, une requête se libère, pas toute la limite. Envoie-la et lis ce qui revient : un autre Retry-After si elle est refusée ou, sur le forfait gratuit, les en-têtes une fois qu'elle est servie.
Les limites de débit ne protègent pas une clé que tu as perdue de vue. Une clé qui a fuité puise dans les mêmes limites que toutes les autres clés de ton compte, et elle peut faire tout ce que ses portées permettent. La révoquer ne rembourse pas les appels qu'elle a déjà faits. Si tu as un doute sur une clé, révoque-la. Voir Sécurité et gestion des clés plus bas.
Conventions
Les champs de réponse sont en camelCase. Les noms des paramètres de requête ne sont pas sensibles à la casse, mais à part ça ils doivent s'écrire exactement comme sur cette page — pageSize et PageSize marchent donc tous les deux. La spec publiée écrit la plupart en PascalCase. La plupart des points de terminaison ignorent une clé de requête qu'ils n'acceptent pas : un filtre mal écrit ne filtre tout simplement pas, alors vérifie ce qui revient. La suppression, l'activation et la désactivation d'une règle font exception : elles refusent toute autre clé avec un 400 qui la nomme. Envoie revert_retroactively avec le trait de soulignement — revertRetroactively est refusé — et seulement à la suppression et à la désactivation, parce que l'activation ne prend que version.
Un champ qui nomme un jour de calendrier est en YYYY-MM-DD. Un champ qui nomme un instant précis est en ISO 8601 avec un décalage horaire.
Les tailles de page sont ramenées dans les bornes, pas refusées. Demande un pageSize de 500 et tu obtiens 100 lignes et un 200, pas une erreur — alors relis pagination.pageSize dans la réponse plutôt que de te fier à ce que tu as envoyé.
Une réponse peut porter des champs que cette page ne liste pas. Ignore ceux que tu ne reconnais pas plutôt que de planter dessus — c'est ce qui garde ton client fonctionnel à mesure que l'API s'étoffe.
REST est du HTTP ordinaire, donc aucun SDK n'est nécessaire pour l'appeler — n'importe quel langage avec un client HTTP fait l'affaire. Rien à installer.
Versionnage et changements
L'API est en bêta, donc ce qui est documenté ici peut changer : un point de terminaison, un champ ou le comportement d'un appel.
Il n'y a pas de numéro de version dans le chemin ni d'en-tête de version. Chaque point de terminaison a une seule version active, et c'est celle documentée ici.
Changelog
Ce qui a changé dans l'Era Developer Platform, dont l'API Era, du plus récent au plus ancien. Il n'y a ni courriel ni flux, alors consulte le changelog quand tu planifies du travail avec l'API.
Sécurité et gestion des clés
Approuver un agent crée une clé
Quand tu approuves un agent en OAuth, Era lui crée une clé d'API. Elle atterrit dans la même liste du tableau de bord que celles que tu crées, sous un nom qu'Era compose à partir du nom du client lui-même.
Comment elle s'appelle
Auto -- ClaudeElle porte exactement les portées que tu as approuvées sur cet écran, et rien d'autre. Révoque-la depuis le tableau de bord et l'agent ne peut plus obtenir de nouvel accès tant que tu ne l'as pas approuvé à nouveau. Un jeton qu'il détient déjà reste valable jusqu'à son expiration, une heure au plus.
Les écritures apparaissent dans ton journal d'activité, pas les lectures
Créer et révoquer une clé apparaissent tous les deux dans ton journal d'activité, tout comme chaque appel d'outil qu'un agent fait en MCP. Une écriture REST y apparaît aussi — comme le changement qu'elle a fait, une étiquette créée ou une transaction modifiée. Une lecture REST ne crée aucune entrée. Era inscrit ces entrées sur tous les forfaits, mais lire le journal complet demande Organize ou plus — en dessous, tu ne vois que les entrées les plus récentes. Les entrées d'une écriture indiquent ton compte, pas la clé qui a fait le changement.
Si jamais tu doutes d'une clé, révoque-la. Une clé que tu as créée toi-même cesse de fonctionner en REST comme en MCP dès sa requête suivante. La clé d'un agent cesse aussitôt d'obtenir de nouveaux accès, et tout jeton qu'il détient déjà expire en moins d'une heure. En refaire une te prend une minute.
- Les portées sont larges
- banking:read couvre bien plus que les lectures de cette page — la même portée couvre aussi le reste des lectures de ton compte : soldes, positions, connexions, dépenses. Une seule portée, il n'y a pas plus étroit. Celles d'écriture sont aussi au menu, comme celles de lecture — alors traite n'importe quelle clé comme un mot de passe. Elle agit comme ton compte Era, pas juste une partie de celui-ci.
- banking:write modifie Era, pas ta banque
- banking:write modifie seulement ce qu'Era conserve, pas ce que ta banque détient. Elle ne peut pas déplacer d'argent ni faire de paiement. Comme banking:read, banking:write est une seule portée, large. Elle couvre les changements que tu peux faire toi-même dans Era, comme la catégorie, le nom du commerçant, la note et le statut de révision d'une transaction ; les catégories, les étiquettes et les règles d'automatisation ; les noms qu'Era affiche pour tes comptes et ceux que tu vois ; et les comptes manuels avec leurs soldes et leurs transactions. Elle peut lancer une nouvelle connexion, mais c'est toujours toi qui te connectes à ta banque, dans le flux du fournisseur et non par la clé. Elle peut demander une nouvelle synchronisation, qui ne fait que lire, ou déconnecter une institution. La déconnexion met fin au lien d'Era, et ton compte à la banque reste ouvert et inchangé.
- Les portées ne se mettent pas à jour
- Les portées d'une clé sont fixées à sa création et ne changent jamais ensuite. Ça compte pour tout ce qu'une portée couvre et qui n'est pas encore activé : accorde social:write aujourd'hui et la clé l'aura encore le jour où les vues partagées arriveront. Accorde ce que tu utilises maintenant, pas ce que tu utiliseras peut-être.
- Aucune approbation requise
- Créer une clé ne passe par aucune revue ni liste d'attente : personne chez Era n'approuve la demande. C'est inscrit dans ton journal d'activité dès que tu la crées, alors une clé que tu ne reconnais pas est facile à repérer.
- L'accès bancaire reste hors de portée
- Une clé n'atteint pas ton accès bancaire, parce qu'Era ne l'a jamais. Tu le saisis dans le flux de connexion géré par le fournisseur de données, pas sur un écran d'Era — ce qu'Era conserve ensuite, c'est un jeton d'accès par connexion, chiffré au repos avec AES-256, que tu peux jeter en débranchant l'institution.
- Era ne garde qu'un haché de ta clé
- Ta clé, c'est 256 bits de données aléatoires. Era la hache en SHA-256 et ne garde que le haché : si tu la perds, révoque-la et crée-en une autre.
Ressources principales
Comptes
Tous les comptes que tu peux voir, à travers chaque institution branchée, avec à côté le nombre de ceux qui sont laissés de côté : excludedAccountCount, séparé en tierExcludedAccountCount pour les comptes que la limite de comptes de ton forfait laisse de côté et userExcludedAccountCount pour ceux que tu as masqués. accountLimit, c'est le nombre de comptes que ton forfait montre à la fois, toutes connexions confondues. accountLimitLift nomme le forfait le moins cher qui a de la place pour tous les comptes que tu n'as pas masqués, et vaut null quand ton forfait ne laisse rien de côté. Chaque compte porte son accountGroupKey — la valeur que le point de terminaison de solde prend dans son chemin — et le connectionId auquel il appartient, alors c'est le premier appel à faire. Accepte connectionId pour se limiter à une seule connexion (les nombres se limitent avec lui, accountLimit et accountLimitLift non), et includeExcluded pour ramener les comptes que ton forfait laisse de côté et ceux que tu as masqués.
- connectionIdoptionnel
- Limite la liste aux comptes d'une seule connexion.
- includeExcludedoptionnel
- Inclut aussi les comptes que ton forfait laisse de côté et ceux que tu as masqués, avec leurs soldes retenus. Le champ visibility de chaque ligne te dit lequel : tierExcluded ou userExcluded, et visible pour les autres. Le point de terminaison de solde écrit ces valeurs autrement, alors n'utilise pas le même analyseur pour les deux. excludedAccountCount revient quand même quand c'est true, et ces comptes sont déjà dans la liste, alors n'additionne pas les deux. Par défaut, false.
{
"accounts": [
{
"accountGroupKey": "uagr_7f3c9a21",
"connectionId": "ucon_4b19e02c",
"name": "Everyday Checking",
"currentBalance": 4820.16,
"supportsTransactions": true,
…
}
],
"excludedAccountCount": 1
}Sur un compte que tu as masqué ou que ton forfait exclut, les champs de solde reviennent à null plutôt qu'à zéro — null veut dire retenu, pas vide. supportsTransactions vaut null dans le même esprit : ça veut dire qu'Era ne peut pas se prononcer, jamais que la réponse est non. Même chose pour les champs du forfait : si Era n'a pas pu lire ton forfait sur cet appel, tierExcludedAccountCount, userExcludedAccountCount, accountLimit et accountLimitLift reviennent tous à null. accountLimit vaut aussi null sur un forfait sans limite de comptes, et accountLimitLift quand aucun forfait n'a plus de place ou quand ton forfait ne laisse rien de côté.
Solde d'un compte
One account's balance, with the credit fields filled in when the account is a liability. The path takes that account's accountGroupKey — the same value /banking/accounts returns for it. The key is not checked for shape before the lookup, so a malformed key and an unknown one answer the same way.
{
"accountGroupKey": "uagr_7f3c9a21",
"currentBalance": 4820.16,
"availableBalance": 4712.03,
"creditLimit": null,
"currencyCode": "USD",
"availableCredit": null,
"asOf": "2026-08-11T09:32:00Z",
"visibility": null
}Un compte masqué, ou un compte dont la connexion a été coupée, répond quand même 200 — avec les champs de solde à null. Un 404 signifie que le compte n'existe vraiment pas, ou que la clé n'avait pas la forme d'une clé. Surveille le champ visibility ici : il vaut null quand le compte est visible, tier_excluded quand la limite de comptes de ton forfait le laisse de côté, user_excluded quand tu l'as masqué, et connection_severed quand sa connexion a été coupée. Avec tier_excluded, accountLimit est la limite de ton forfait et accountLimitLift nomme le forfait le moins cher qui a de la place pour tous les comptes que tu n'as pas masqués, celui-ci compris. accountLimitLift vaut null dans tous les autres états, et avec connection_severed, accountLimit vaut null aussi.
Sommaire des comptes
Les totaux sur les comptes que tu peux voir, par défaut les comptes réels : totalAssets, totalLiabilities et netWorthHint, qui est le premier moins le second. Passe simulationModes pour choisir quels modes comptent : la liste des comptes et les totaux ne couvrent que ceux que tu nommes. includedSimulationModes indique quels modes ils couvrent, dans chaque réponse. simulationExcludedAccountCount compte les comptes que tu peux voir et qui ont été laissés de côté à cause de leur mode. totalHiddenCount est un décompte à part : les comptes que ton offre ou ton propre réglage de visibilité masque, quel que soit le mode, et jamais ceux que simulationModes a laissés de côté.
- simulationModesoptionnel
- Quels types de comptes totaliser : live pour l'argent réel, paper pour le compte d'entraînement d'un courtier, scenario pour un compte hypothétique. Répète le paramètre pour en demander plusieurs, comme dans simulationModes=live&simulationModes=paper. Sans lui, seuls les comptes réels sont comptés. Une valeur vide ou inconnue est refusée avec un 400 qui liste les valeurs autorisées.
{
"userId": "7d1c0b93a8e24f60",
"accounts": [ … ],
"totalVisibleCount": 6,
"totalHiddenCount": 2,
"totalAssets": 48210.75,
"totalLiabilities": 9327.40,
"netWorthHint": 38883.35,
"includedSimulationModes": [ "live" ],
"simulationExcludedAccountCount": 0,
"computedAt": "2026-08-11T09:32:00Z"
}netWorthHint ne compte que les comptes présents dans cette réponse, et deux décomptes te disent ce qu'il laisse de côté. simulationExcludedAccountCount, ce sont les comptes en dehors des modes demandés. totalHiddenCount, ce sont les comptes qui te sont masqués, quel que soit le mode. Il se divise en deux : tierExcludedAccountCount pour ceux que la limite de comptes de ton forfait laisse de côté, et userExcludedAccountCount pour ceux que tu as masqués toi-même. Les deux valent null si Era n'a pas pu lire ton forfait lors de cet appel. accountLimitLift nomme le forfait le moins cher qui ramène les premiers, et vaut null lorsqu'il n'y en a aucun. Prends netWorthHint comme un chiffre de départ plutôt que comme une valeur nette faisant autorité.
Transactions
Tes transactions, une page à la fois, enveloppées avec les compteurs de pagination à côté. Accepte page et pageSize (100 au maximum), plus des filtres optionnels par compte, plage de dates, règles appliquées et étiquettes assignées.
- accountIdoptionnel
- Limite aux transactions d'un compte, par son accountGroupKey.
- fromDateoptionnel
- Seulement les transactions à cette date ou après.
- toDateoptionnel
- Seulement les transactions à cette date ou avant.
- pageoptionnel
- Numéro de page, à partir de 1. Par défaut, 1.
- pageSizeoptionnel
- Lignes par page. Par défaut, 50, plafonné à 100.
- sortByoptionnel
- Champ de tri : transactionDate, amount, description, category ou merchantName.
- sortDirectionoptionnel
- asc ou desc. Par défaut, décroissant.
- categoryKeysoptionnel
- Only transactions in these categories, by their fcat_ keys. Takes a list, not a single key, and a transaction matches if its effective category is any one of them. Send the literal "uncategorized" to select the transactions that have no category at all.
- searchoptionnel
- Recherche plein texte sur le commerçant, la description, la catégorie, le nom du compte et le montant.
- ruleIdsoptionnel
- Seulement les transactions qu'une règle d'automatisation a touchées, par la clé de la règle.
- tagKeysoptionnel
- Seulement les transactions qui portent l'une de ces étiquettes.
- reviewStatusesoptionnel
- needs_review, reviewed ou flagged. Accepte une liste ; une transaction correspond si son statut de révision est l’un d’eux.
- includeChildrenoptionnel
- With a category filter set, also include transactions in the subcategories of every key you passed. Defaults to false.
- includePendingoptionnel
- Retourne aussi les transactions en attente des 7 derniers jours, marquées isPending. Par défaut, false. Les lignes en attente sont en lecture seule.
{
"transactions": [ … ],
"pagination": {
"currentPage": 1,
"pageSize": 20,
"totalItems": 412,
"totalPages": 21
},
"historyWindowApplied": true,
"historyWindowFloorDate": "2026-06-28",
"historyWindowHiddenCount": 137,
"historyWindowEarliestDate": "2024-03-02",
"historyWindowDegraded": false
}Ton forfait peut appliquer un plancher de fenêtre d'historique, qui cache les transactions plus anciennes que lui. C'est pour ça que la réponse porte les champs historyWindow : historyWindowApplied te dit qu'un plancher a bel et bien caché quelque chose, historyWindowFloorDate indique où il tombe, historyWindowHiddenCount combien de lignes sont derrière, et historyWindowEarliestDate jusqu'où ton historique remonte vraiment. Sans eux, un résultat court est impossible à distinguer d'un compte sans transactions plus anciennes. Deux d'entre eux changent ce que tu écris : historyWindowHiddenCount peut valoir null même quand un plancher s'est appliqué, alors lis null comme une valeur inconnue plutôt que comme un zéro; et quand historyWindowDegraded vaut true, Era n'a pas pu confirmer ton forfait sur cette lecture, donc la date du plancher est une supposition et non un fait. Sur une lecture payante confirmée, aucun plancher ne s'applique et historyWindowApplied revient à false. La limite de comptes de ton forfait laisse aussi des transactions de côté : tierExcludedAccountCount te dit combien de tes comptes elle garde hors de cette lecture, et userExcludedAccountCount combien tu en as masqué — les deux limités au compte sur lequel tu filtres, si tu en filtres un. Les deux valent null quand Era n'a pas pu lire ton forfait sur cet appel.
Parcourir un long historique page par page consomme des requêtes. Ton forfait plafonne la vitesse à laquelle tu peux appeler et, sur le forfait gratuit, le nombre d'appels par jour; les forfaits payants fonctionnent selon une utilisation raisonnable. Limites donne les chiffres par forfait, les en-têtes de limite et ce que dit un 429.
Modifier une transaction
Quatre choses sur une transaction sont à toi de redéfinir : sa catégorie, le nom du commerçant, une note de ton choix, et son statut de révision. Envoie seulement celles que tu changes — tout ce que tu omets reste tel quel. L'id dans le chemin est la clé utgr_ de la transaction. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement la copie de la transaction chez Era : celle à ta banque reste telle quelle.
- categoryKeyoptionnel
- La clé fcat_ de la catégorie à assigner. Omets ce paramètre et la transaction garde la catégorie qu'elle a déjà.
- merchantNameoptionnel
- Un nom de commerçant de ton choix, jusqu'à 1000 caractères. Omets ce paramètre et le nom actuel reste.
- descriptionoptionnel
- Une note de ton choix sur cette transaction, jusqu'à 5000 caractères. Omets ce paramètre et la note actuelle reste.
- clearCategoryoptionnel
- Retire ta redéfinition de catégorie, pour que la catégorisation d'Era reprenne le dessus. Par défaut, false.
- clearMerchantNameoptionnel
- Retire ta redéfinition du nom de commerçant, pour que le nom envoyé par ta banque revienne. Par défaut, false.
- clearDescriptionoptionnel
- Retire ta redéfinition de la description, pour que la description envoyée par ta banque revienne. Par défaut, false.
- reviewStatusoptionnel
- Marque-la needs_review, reviewed ou flagged.
- clearReviewStatusoptionnel
- Retire ta redéfinition du statut de révision. Par défaut, false.
{
"transaction": { … }
}Tu récupères la transaction mise à jour au complet, dans la même forme que retourne la liste ci-dessus — non reproduite ici, parce qu'elle est volumineuse et change encore tant que l'API est en bêta. Définir un champ et le vider dans le même appel te donne 400. Une transaction qui n'est pas la tienne, ou qui n'existe pas du tout, te donne 403 — l'API ne fait pas la différence entre les deux. Et si autre chose a changé la même ligne pendant que tu écrivais, tu obtiens 409 : relis-la et renvoie-la.
Modifier jusqu'à 100 à la fois
Les quatre mêmes redéfinitions, appliquées à une liste de transactions en un seul appel. Chaque id de la liste reçoit les mêmes changements — il n'y a pas de variation par transaction. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement les copies de ces transactions chez Era : celles à ta banque restent telles quelles.
- transactionIds
- Les clés utgr_ des transactions à modifier. Au moins une, et au plus 100. Au-delà de 100, c'est refusé plutôt que tronqué — contrairement à pageSize plus haut, tu obtiens un 400 et rien n'est modifié.
- categoryKeyoptionnel
- La clé fcat_ de la catégorie à assigner. Omets ce paramètre et la transaction garde la catégorie qu'elle a déjà.
- merchantNameoptionnel
- Un nom de commerçant de ton choix, jusqu'à 1000 caractères. Omets ce paramètre et le nom actuel reste.
- descriptionoptionnel
- Une note de ton choix sur cette transaction, jusqu'à 5000 caractères. Omets ce paramètre et la note actuelle reste.
- clearCategoryoptionnel
- Retire ta redéfinition de catégorie, pour que la catégorisation d'Era reprenne le dessus. Par défaut, false.
- clearMerchantNameoptionnel
- Retire ta redéfinition du nom de commerçant, pour que le nom envoyé par ta banque revienne. Par défaut, false.
- clearDescriptionoptionnel
- Retire ta redéfinition de la description, pour que la description envoyée par ta banque revienne. Par défaut, false.
- reviewStatusoptionnel
- Marque-la needs_review, reviewed ou flagged.
- clearReviewStatusoptionnel
- Retire ta redéfinition du statut de révision. Par défaut, false.
{
"transactions": [ … ]
}Tu récupères les transactions mises à jour, dans la même forme que retourne la liste ci-dessus. Définir un champ et le vider dans le même appel te donne 400, tout comme une liste vide. Une liste contenant une transaction qui n'est pas la tienne, ou qui n'existe pas du tout, te donne 403 pour l'appel entier — rien n'est modifié. Si autre chose a changé l'une de ces lignes pendant que tu écrivais, tu obtiens 409 : relis-les et renvoie-les.
Catégories
Toute la taxonomie des catégories : chaque ensemble de catégories, avec ses sous-catégories imbriquées dedans. La taxonomie est partagée, pas propre à un compte.
{
"packs": [
{
"packSlug": "default",
"packName": "Era default categories",
"isDefault": true,
"categories": [
{
"projectionKey": "fcat_food_dining",
"categoryName": "Food & dining",
"isTopLevel": true,
"children": [ … ]
}
]
}
],
"meterLimit": 25,
"canCreateCustomCategories": true
}Ajouter une catégorie
Une catégorie définie par l'utilisateur, sous un parent existant. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes catégories dans Era : rien ne change à ta banque.
- slug
- Identifiant compatible URL — lettres minuscules, chiffres et traits d'union, de 2 à 50 caractères.
- parentCategoryKey
- La clé fcat_ de la catégorie sous laquelle celle-ci s'imbrique.
- name
- Nom affiché.
- descriptionoptionnel
- Description optionnelle.
- iconNameoptionnel
- Nom d'icône optionnel.
- spendingTypeoptionnel
- Classification de dépense optionnelle.
- displayOrderoptionnel
- Position de tri optionnelle parmi ses catégories sœurs.
- assignmentEligibilityoptionnel
- Règle optionnelle sur les transactions auxquelles cette catégorie peut être assignée.
- sourceSystemKeysoptionnel
- Liste optionnelle de clés de catégories existantes dont les transactions doivent être redirigées ici à partir de maintenant.
- applyRetroactivelyoptionnel
- Si true, réévalue aussi les transactions passées selon le nouvel acheminement. Par défaut, false.
{
"categoryKey": "fcat_side_hustle_9f2a",
"overlayProjectionKey": "fcov_9f2a1c",
"action": "created",
"isQuotaExceeded": false,
"createdMappingRuleKeys": [ … ],
…
}La réponse porte aussi retroactiveAffectedCount, mergeSourcesHiddenCount et mergeSourcesTotalCount, que cette page ne couvre pas, ainsi qu'isQuotaExceeded, quotaExceededMessage et meterGate, qui valent toujours false, null et null sur une catégorie créée. Si le quota de ton forfait refuse la création, tu reçois plutôt un 402 sans aucun de ces champs : son corps contient statusCode, message et errors.generalErrors, dont l'unique entrée te dit quelle limite tu as atteinte.
Étiquettes
Toutes les étiquettes de ton compte, en une seule liste. Pas de pagination — une seule réponse te les retourne toutes.
- tagTypeoptionnel
- Filtre par origine de l'étiquette : user, system ou auto.
- includeDeletedoptionnel
- Inclut les étiquettes supprimées. Par défaut, false.
{
"tags": [
{
"tagKey": "utag_9c2f01ab",
"name": "business-expense",
"displayName": "Business expense",
"tagType": "user",
"color": "#6DC6BA",
"transactionCount": 42
}
]
}Créer une étiquette
Une nouvelle étiquette, normalisée en minuscules. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes étiquettes dans Era : rien ne change à ta banque. Les étiquettes système ne peuvent pas être créées par l'API ; les étiquettes user et auto, oui.
- name
- Le nom canonique de l'étiquette.
- displayNameoptionnel
- Nom affiché optionnel. Par défaut, le nom canonique.
- tagTypeoptionnel
- user or auto. Defaults to user. system is refused — it is reserved for tags Era creates itself.
- coloroptionnel
- Couleur hexadécimale optionnelle pour l'affichage.
- iconoptionnel
- Nom d'icône optionnel.
{
"tag": {
"tagKey": "utag_9c2f01ab",
"name": "business-expense",
"displayName": "Business expense",
"tagType": "user",
"version": 1,
"createdAt": "2026-08-26T09:15:00Z"
}
}Règles
Toutes les règles d'automatisation de ton compte — celles que tu as créées et celles qu'Era a configurées pour toi à partir de sa bibliothèque de règles — chacune avec ses conditions (filters), ce qu'elle fait (actions), si elle est activée, et sa version. Pas de pagination : une seule réponse te les retourne toutes. Les règles désactivées sont laissées de côté, sauf si tu les demandes.
- includeInactiveoptionnel
- Retourne aussi les règles désactivées. Par défaut, false.
{
"rules": [
{
"id": "rule_4c1e7a90",
"ruleName": "Coffee shops",
"isActive": true,
"version": 3,
"priority": 10,
"filters": [{ "type": "merchant_match", "pattern": "Blue Bottle", "mode": "contains" }],
"actions": [{ "type": "set_category", "categoryKey": "fcat_coffee_shops", "categoryDisplayName": "Coffee shops" }],
"source": "user",
"matchedTransactionCount": 42,
…
}
]
}filters et actions sont des listes d'objets typés. Chacun indique sa sorte dans un champ type — merchant_match ou category parmi les filtres, set_category ou add_tag parmi les actions — et le document OpenAPI lié dans le démarrage rapide liste chaque sorte et les champs qu'elle prend.
Créer une règle
Une nouvelle règle d'automatisation : des conditions qui choisissent des transactions, et ce qui arrive à chacune qu'elles visent. Elle s'applique à chaque nouvelle transaction à partir de là, et à celles que tu as déjà si tu le demandes. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes règles et tes transactions dans Era : rien ne change à ta banque.
- ruleName
- Un nom pour la règle.
- descriptionoptionnel
- Une note facultative sur ce à quoi sert la règle.
- priorityoptionnel
- La place de la règle parmi tes autres : la plus haute passe en premier, et quand deux règles définiraient la même chose sur une transaction, la plus haute l'emporte. Par défaut, zéro.
- filters
- Les conditions, sous forme de liste d'objets de filtre typés — chacun indique sa sorte dans un champ type. Une transaction doit toutes les remplir ; imbrique des filtres and, or et not pour les combiner autrement. Au moins une. Un filtre account_type qui indique des types de compte ne fonctionne que sur une règle de motif ; sur une règle de transaction, il est refusé avec un 400.
- actions
- Ce qui arrive à chaque transaction que la règle vise, sous forme de liste d'objets d'action typés : attribuer une catégorie, ajouter ou retirer une étiquette, renommer le commerçant, réécrire la description, définir un statut de révision, la masquer, ou la marquer comme un virement. Au moins une, et pas plus d'une de chaque sorte, sauf les actions d'étiquettes. Chaque étiquette doit déjà exister, et ne peut apparaître qu'une fois.
- isActiveoptionnel
- Si la règle commence activée. Par défaut, true.
- applyRetroactivelyoptionnel
- Passe aussi la règle sur les transactions que tu as déjà, pas seulement les nouvelles. Ça ne s'applique que si la règle commence activée. Par défaut, false.
- appliesFromoptionnel
- Seulement les transactions à cette date ou après.
- appliesTooptionnel
- Seulement les transactions à cette date ou avant.
- applicationScopeoptionnel
- Quand la règle s'applique : prospective pour les nouvelles transactions seulement, retroactive quand on la passe sur les existantes, ou both. Par défaut, both.
- ruleScopeoptionnel
- transaction, la valeur par défaut, vise les transactions une à une. pattern repère un motif sur plusieurs — un prélèvement récurrent, une paire de virements — décrit par patternSpec.
- triggerModeoptionnel
- Pour une règle de motif, quand chercher le motif : onEachTransaction, onBatchComplete, onSchedule ou onDemand. Par défaut, onEachTransaction.
- patternSpecoptionnel
- Pour une règle de motif, le motif à chercher, sous forme d'objet typé. Obligatoire quand ruleScope vaut pattern.
- windowDaysoptionnel
- Pour une règle de motif, combien de jours en arrière chercher le reste du motif, entre 1 et 365. Obligatoire quand ruleScope vaut pattern.
- windowLookaheadDaysoptionnel
- Pour une règle de motif, combien de jours en avant chercher le reste du motif.
- windowExcludeTriggerAccountoptionnel
- Pour une règle de motif, laisse hors de la recherche le compte de la transaction qui a lancé la vérification. Par défaut, false.
- groupoptionnel
- Le groupe où classer la règle : spendingHabits, problemsAndAnomalies, incomeAndTransfers, subscriptionsAndRecurring ou taxAndRecordKeeping. Omets-le pour ne la classer dans aucun. categoryMapping est réservé aux règles qu'Era crée elle-même, et il est refusé avec un 400.
{
"rule": { … },
"retroactiveStatus": "completed",
"affectedTransactionCount": 18
}retroactiveStatus vaut null, sauf si tu as demandé à l'appel d'appliquer la règle à des transactions que tu avais déjà, ou de défaire ce qu'elle a fait. completed veut dire que ce travail s'est terminé avant la réponse ; in_progress, qu'il roule encore, donc affectedTransactionCount n'est pas final ; queue_full, que la file était pleine et qu'il n'a pas commencé — le changement à la règle elle-même a quand même été enregistré ; partial_success, que seulement une partie a passé — certains changements n'ont pas été enregistrés, ou seulement une partie du travail a été mise en file.
Prévisualiser une règle
Essaie les conditions d'une règle sur tes transactions récentes et te dit ce qu'elles viseraient, sans rien enregistrer : combien correspondent sur combien ont été vérifiées, jusqu'à 50 des clés des correspondances, et jusqu'à 10 échantillons. Une règle de transaction vérifie les 90 derniers jours, au plus 5 000 transactions, et ses échantillons portent le commerçant, le montant et la date. Les échantillons d'une règle de motif portent detectionReason, la raison pour laquelle le motif a été détecté (qui peut être vide), sans commerçant, montant ni date. Rien n'est écrit, alors banking:read suffit.
- filters
- Les conditions, sous forme de liste d'objets de filtre typés — chacun indique sa sorte dans un champ type. Une transaction doit toutes les remplir ; imbrique des filtres and, or et not pour les combiner autrement. Au moins une. Un filtre account_type qui indique des types de compte ne fonctionne que sur une règle de motif ; sur une règle de transaction, il est refusé avec un 400.
- ruleScopeoptionnel
- transaction, la valeur par défaut, vise les transactions une à une. pattern repère un motif sur plusieurs — un prélèvement récurrent, une paire de virements — décrit par patternSpec.
- patternSpecoptionnel
- Pour une règle de motif, le motif à chercher, sous forme d'objet typé. Obligatoire quand ruleScope vaut pattern.
- windowDaysoptionnel
- Pour une règle de motif, combien de jours en arrière chercher le reste du motif, entre 1 et 365. Obligatoire quand ruleScope vaut pattern.
{
"matchCount": 12,
"totalEvaluated": 418,
"matchingGroupKeys": ["utgr_5d0e2b77", … ],
"sampleMatches": [
{
"groupKey": "utgr_5d0e2b77",
"merchantName": "Blue Bottle Coffee",
"amount": -6.25,
"currency": "USD",
"transactionDate": "2026-09-12"
},
…
]
}Modifier une règle
Remplace la définition d'une règle par celle que tu envoies, alors envoie chaque champ que tu veux garder — pas seulement ceux que tu changes. Le ruleId dans le chemin est l'id que la liste des règles retourne, et version doit être celle que tu as lue la dernière fois. Sur une règle de la bibliothèque d'Era, seul userOverrides peut changer : renvoie tout le reste tel que la liste te l'a retourné. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes règles et tes transactions dans Era : rien ne change à ta banque.
- versionoptionnel
- La version de la règle telle que tu l'as lue la dernière fois. Elle doit correspondre à la version actuelle, sinon l'appel est refusé avec un 409 — alors l'omettre ne saute pas la vérification, ça la fait échouer.
- ruleName
- Un nom pour la règle.
- descriptionoptionnel
- Une note facultative sur ce à quoi sert la règle.
- priorityoptionnel
- La place de la règle parmi tes autres : la plus haute passe en premier, et quand deux règles définiraient la même chose sur une transaction, la plus haute l'emporte. Par défaut, zéro.
- filters
- Les conditions, sous forme de liste d'objets de filtre typés — chacun indique sa sorte dans un champ type. Une transaction doit toutes les remplir ; imbrique des filtres and, or et not pour les combiner autrement. Au moins une. Un filtre account_type qui indique des types de compte ne fonctionne que sur une règle de motif ; sur une règle de transaction, il est refusé avec un 400.
- actions
- Ce qui arrive à chaque transaction que la règle vise, sous forme de liste d'objets d'action typés : attribuer une catégorie, ajouter ou retirer une étiquette, renommer le commerçant, réécrire la description, définir un statut de révision, la masquer, ou la marquer comme un virement. Au moins une, et pas plus d'une de chaque sorte, sauf les actions d'étiquettes. Chaque étiquette doit déjà exister, et ne peut apparaître qu'une fois.
- applyRetroactivelyoptionnel
- Repasse la règle modifiée sur les transactions que tu as déjà, en défaisant d'abord ce que l'ancienne version leur a fait. Par défaut, false.
- appliesFromoptionnel
- Seulement les transactions à cette date ou après.
- appliesTooptionnel
- Seulement les transactions à cette date ou avant.
- applicationScopeoptionnel
- Quand la règle s'applique : prospective pour les nouvelles transactions seulement, retroactive quand on la passe sur les existantes, ou both. Par défaut, both.
- userOverridesoptionnel
- Sur une règle de la bibliothèque d'Era, tes propres valeurs pour les réglages qu'elle te laisse ajuster, sous forme d'objet typé de la même sorte que le motif de la règle. Ignoré sur les règles que tu as créées.
- groupoptionnel
- Le groupe où classer la règle, dans la même liste que la création accepte. La modification remplace toute la définition, alors l'omettre retire le groupe de la règle — envoie son groupe actuel pour le garder. Sur une règle de la bibliothèque d'Era, omets-le ou envoie le groupe qu'elle a déjà.
{
"rule": { … },
"retroactiveStatus": null,
"affectedTransactionCount": 0
}retroactiveStatus vaut null, sauf si tu as demandé à l'appel d'appliquer la règle à des transactions que tu avais déjà, ou de défaire ce qu'elle a fait. completed veut dire que ce travail s'est terminé avant la réponse ; in_progress, qu'il roule encore, donc affectedTransactionCount n'est pas final ; queue_full, que la file était pleine et qu'il n'a pas commencé — le changement à la règle elle-même a quand même été enregistré ; partial_success, que seulement une partie a passé — certains changements n'ont pas été enregistrés, ou seulement une partie du travail a été mise en file.
Activer une règle
Réactive une règle, pour qu'elle s'applique de nouveau aux nouvelles transactions. Activer une règle déjà activée ne change rien. Les règles de la bibliothèque d'Era s'activent et se désactivent comme les tiennes. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes règles et tes transactions dans Era : rien ne change à ta banque.
- versionoptionnel
- La version de la règle telle que tu l'as lue la dernière fois. Omets-la pour sauter la vérification ; si tu l'envoies, l'appel est refusé avec un 409 quand la règle a changé depuis.
{
"rule": { … },
"retroactiveStatus": null,
"affectedTransactionCount": 0
}Désactiver une règle
Désactive une règle, pour qu'elle ne s'applique plus aux nouvelles transactions. Elle garde sa définition, et ce qu'elle a déjà fait reste en place, sauf si tu le demandes en retour avec revert_retroactively. Désactiver une règle déjà désactivée la laisse désactivée. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes règles et tes transactions dans Era : rien ne change à ta banque.
- versionoptionnel
- La version de la règle telle que tu l'as lue la dernière fois. Omets-la pour sauter la vérification ; si tu l'envoies, l'appel est refusé avec un 409 quand la règle a changé depuis.
- revert_retroactivelyoptionnel
- Défait aussi ce que la règle a déjà fait à tes transactions — les catégories, étiquettes et autres changements qu'elle a appliqués. Par défaut, false, ce qui laisse ces changements en place.
{
"rule": { … },
"retroactiveStatus": null,
"affectedTransactionCount": 0
}retroactiveStatus vaut null, sauf si tu as demandé à l'appel d'appliquer la règle à des transactions que tu avais déjà, ou de défaire ce qu'elle a fait. completed veut dire que ce travail s'est terminé avant la réponse ; in_progress, qu'il roule encore, donc affectedTransactionCount n'est pas final ; queue_full, que la file était pleine et qu'il n'a pas commencé — le changement à la règle elle-même a quand même été enregistré ; partial_success, que seulement une partie a passé — certains changements n'ont pas été enregistrés, ou seulement une partie du travail a été mise en file.
Supprimer une règle
Supprime une règle pour de bon. Pour arrêter une règle sans la perdre, désactive-la plutôt. Le ruleId dans le chemin est l'id que la liste des règles retourne, et version doit être celle que tu as lue la dernière fois. Les règles de la bibliothèque d'Era ne peuvent pas être supprimées, seulement désactivées. Ça prend banking:write plutôt que banking:read, mais ça modifie seulement tes règles et tes transactions dans Era : rien ne change à ta banque. Demander revert_retroactively à une suppression, c'est un seul essai : si ça revient avec queue_full, la règle est déjà partie et il ne reste plus rien sur quoi réessayer. Pour supprimer une règle et défaire ce qu'elle a fait, désactive-la d'abord avec revert_retroactively — tu peux recommencer jusqu'à ce que ce soit accepté —, puis supprime-la.
- versionoptionnel
- La version de la règle telle que tu l'as lue la dernière fois. Elle doit correspondre à la version actuelle, sinon l'appel est refusé avec un 409 — alors l'omettre ne saute pas la vérification, ça la fait échouer.
- revert_retroactivelyoptionnel
- Défait aussi ce que la règle a déjà fait à tes transactions — les catégories, étiquettes et autres changements qu'elle a appliqués. Par défaut, false, ce qui laisse ces changements en place.
{
"success": true,
"retroactiveStatus": null,
"affectedTransactionCount": 0
}retroactiveStatus vaut null, sauf si tu as demandé à l'appel d'appliquer la règle à des transactions que tu avais déjà, ou de défaire ce qu'elle a fait. completed veut dire que ce travail s'est terminé avant la réponse ; in_progress, qu'il roule encore, donc affectedTransactionCount n'est pas final ; queue_full, que la file était pleine et qu'il n'a pas commencé — le changement à la règle elle-même a quand même été enregistré ; partial_success, que seulement une partie a passé — certains changements n'ont pas été enregistrés, ou seulement une partie du travail a été mise en file.