API Era
Découvrez les points de terminaison disponibles, les en-têtes d'authentification, la pagination et les limites de l'API Era.
Dernière mise à jour : 29 septembre 2026
Ces points de terminaison fonctionnent dès aujourd'hui, mais l'API continue d'évoluer, donc certains détails peuvent changer. Consultez la date de dernière mise à jour en haut de page pour savoir quand elle a été révisée pour la dernière fois.
Démarrage rapide
Avant de commencer, il vous faut un compte Era avec au moins un établissement connecté — sans connexion, ces points de terminaison n'ont rien à renvoyer.
- 1
Connectez-vous à Era et reliez un établissement, si ce n'est pas déjà fait.
- 2
Ouvrez vos clés d'API dans le tableau de bord et créez une clé. Toutes les portées sont cochées au départ, donc décochez celles dont vous n'avez pas besoin — pour ces points de terminaison, il ne reste que banking:read. Vous choisissez aussi une expiration ; il n'existe pas d'option « n'expire jamais ».
- 3
Copiez la clé. Elle ne s'affiche qu'une fois, et nous ne pouvons pas la réafficher. Copiez-la et conservez-la en lieu sûr, par exemple dans un gestionnaire de secrets. Si vous perdez une clé, vous ne pouvez plus la consulter. Créez-en une nouvelle à la place.
- 4
Envoyez-la dans un en-tête avec votre 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
}API disponibles
L'API Era comprend les API suivantes :
- GET
- GET/banking
/accounts /{accountId} /balanceLe solde d'un compte, avec les champs de crédit renseignés s'il s'agit d'un passif. - GET/banking
/accounts /summaryLes totaux sur tous les comptes que vous pouvez voir. - GET/banking
/transactionsVos transactions, une page à la fois. - PUT/banking
/transactions /{id}Modifier une transaction - PUT/banking
/transactions /bulkModifier jusqu'à 100 à la fois - GET/banking
/categoriesToute la taxonomie des catégories, avec les sous-catégories imbriquées. - POST/banking
/categoriesAjouter une catégorie - GET
- POST/banking
/tagsCréer une étiquette
Authentification
Envoyez votre 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 vous choisissez au bout de combien de temps au moment de les créer. 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 », donc tout ce que vous construisez là-dessus doit prévoir la rotation de la clé avant qu'elle n'expire.
En-têtes de réponse
Un ID de requête revient sur chaque réponse. Les en-têtes de limite reviennent sur les appels qu'Era a mesurés par rapport à un budget quotidien, et sur un 429 seulement quand ce budget quotidien a refusé l'appel : un 429 du plafond de rafale par minute ne porte que Retry-After. Pour l'instant, seul le forfait gratuit a un budget quotidien. Si Era ne peut pas mesurer votre usage, l'appel est servi sans aucun de ces en-têtes.
- fly-request-id
- Un identifiant unique pour la requête. Indiquez-le lorsque vous contactez le support à propos d'une requête précise — voir ID de requête
- X-RateLimit-Limit
- Le budget quotidien de votre forfait. Envoyé uniquement sur les forfaits qui ont un budget quotidien, et jamais sur un 429 du plafond de rafale par minute.
- X-RateLimit-Remaining
- Ce qu'il reste de votre budget quotidien. Jamais en dessous de zéro. Envoyé uniquement sur les forfaits qui ont un budget quotidien, et jamais sur un 429 du plafond de rafale par minute.
- X-RateLimit-Reset
- Quand votre 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 ont un budget quotidien, et jamais sur un 429 du plafond de rafale par minute. Le plafond de rafale par minute n'a pas d'en-tête à lui. Voir Limites
- Retry-Afterseulement sur un 429
- Le nombre de secondes à attendre avant de réessayer, selon la limite qui a refusé la requête. Un 429 qui porte aussi X-RateLimit-* a été refusé par le budget quotidien ; sans eux, par le plafond de rafale par minute. 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, ou une écriture qui définit et efface le même champ dans le même appel.
- 401
Pas de clé, ou une clé qui ne s'analyse pas. Envoyez-la dans l'en-tête X-API-Key ou comme jeton bearer.
- 402
Un quota de forfait fait obstacle — aujourd'hui, cela ne concerne que la création de catégories. Il s'agit de ce que vous créez, pas de la vitesse à laquelle vous appelez : attendre n'y change rien, un forfait supérieur si. 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.
- 404
Un compte qui n'existe pas. Seul l'endpoint de solde le renvoie : un accountGroupKey qui ne désigne aucun compte, ou qui n'a même pas la forme d'une clé, revient en 404 sans corps. Les transactions ne renvoient jamais 404 — voir 403.
- 409
Autre chose a modifié la ligne pendant que vous écriviez. Relisez-la et renvoyez votre écriture.
- 429
Trop de requêtes. Vous avez atteint le plafond de rafale par minute ou, sur le forfait gratuit, épuisé votre budget quotidien. Un 429 avec les en-têtes X-RateLimit-* vient du budget quotidien, et un 429 sans eux, du plafond de rafale. Retry-After indique combien de temps attendre et, contrairement à un 402, attendre libère votre prochaine requête. Voir Limites pour les chiffres par forfait.
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 un 404 reviennent sans corps du tout, alors lisez 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"]
}
}ID de requête
Chaque réponse porte un en-tête fly-request-id. Indiquez-le lorsque vous contactez le support à propos d'une requête précise.
# Print the response headers, including fly-request-id; discard the body
curl -sS -D - -o /dev/null "https://forge.era.app/api/banking/transactions?page=1&pageSize=20" \
-H "X-API-Key: fmk_your_key_here"# A write call: same header, plus a JSON body
curl -sS -D - -X PUT "https://forge.era.app/api/banking/transactions/utgr_your_transaction_id" \
-H "X-API-Key: fmk_your_key_here" \
-H "Content-Type: application/json" \
-d '{"categoryKey": "fcat_dining", "merchantName": "Corner Cafe"}'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 vôtre, ou qui n'existe pas — 403, jamais 404. La réponse ne vous dit donc jamais si un id existe, seulement qu'il n'est pas à vous.
Autre chose a modifié la ligne en premier — 409.
Limites
Deux des dix endpoints documentés plafonnent ce que vous pouvez demander en un seul appel. Les huit 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 peut atteindre un quota de forfait, votre forfait peut toujours masquer l'historique ancien, et chaque appel compte dans les limites de débit de votre forfait, décrites ci-dessous.
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 et l'écriture d'une seule transaction n'ont aucun plafond de volume par appel. Vous recevez l'ensemble complet, ou la seule ligne que vous avez nommée.
pageSize est plafonné à 100, jamais refusé. Demandez-en plus et vous recevez 100 lignes avec un 200 — lisez pagination.pageSize dans la réponse plutôt que de faire confiance à ce que vous avez envoyé.
L'écriture groupée de transactions est plafonnée à 100 id, et contrairement à pageSize elle est refusée plutôt que plafonnée : envoyez 101 et vous recevez un 400, rien ne change.
Les clés expirent selon un calendrier que vous choisissez à la création — jusqu'à 90 jours sur le forfait gratuit, 365 sur un forfait payant. Il n'existe pas d'option sans expiration.
Votre 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
L'API applique 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 vous l'avez faite, et dans le budget quotidien un jour après. Les forfaits payants n'ont pas de budget quotidien pour l'instant : sur un forfait payant, le plafond de rafale est donc la seule limite. Dépassez l'une ou l'autre et l'appel revient en 429.
Les limites appartiennent à votre compte, pas à une clé. Chaque clé REST que vous créez puise dans le même plafond de rafale et, sur le forfait gratuit, dans le même budget quotidien : une deuxième clé ne vous 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 les uns des autres.
| Forfait | Budget quotidien | Plafond de rafale |
|---|---|---|
| Basic | 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.
Les forfaits payants fonctionnent aussi selon un usage raisonnable. C'est une politique, pas un compteur : l'API ne refuse donc jamais un appel pour cela. L'API est faite pour des scripts, des tableaux de bord et des intégrations sur vos propres données financières, à un volume qui convient à une personne. Si nous estimons que votre usage va au-delà, nous ne couperons pas votre compte sans vous contacter d'abord. Sur la page des tarifs, cela s'appelle « Illimité (usage raisonnable) pour l'instant ».
Sur le forfait gratuit, chaque réponse servie indique votre budget quotidien dans les en-têtes X-RateLimit-* décrits sous En-têtes de réponse. Les réponses d'un forfait payant n'en portent aucun. Aucun en-tête n'indique le plafond de rafale, sur aucun forfait : réglez donc votre rythme sur le tableau. Sur le forfait gratuit, Remaining peut être bien au-dessus de zéro juste avant qu'une rafale revienne en 429. Si Era ne peut pas mesurer votre usage, il sert l'appel sans les en-têtes : sur le forfait gratuit, lisez une réponse sans en-têtes comme un compte inconnu, pas comme une erreur.
Ce que dit un 429
Quelle limite vous a refusé. Un 429 qui porte les en-têtes X-RateLimit-* vient du budget quotidien ; un 429 sans eux, du plafond de rafale. C'est vrai sur tous les forfaits. Le corps est au format problem-details, et son champ detail précise la limite, ce qu'elle permet, quand votre prochaine requête se libère et le forfait qui la relève ou la supprime, ou que vous êtes déjà sur le plus élevé. Il est écrit pour des humains : lisez 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, jamais moins d'une. C'est jusqu'à une minute pour le plafond de rafale et jusqu'à 24 heures pour le budget quotidien du forfait gratuit. Un appel refusé ne compte dans aucune des deux limites, mais une nouvelle tentative avant la fin de Retry-After est refusée à son tour : attendez donc. Ensuite, une requête se libère, pas toute la limite. Envoyez-la et lisez 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 vous avez perdue de vue. Une clé qui a fuité puise dans les mêmes limites que toutes les autres clés de votre 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 vous avez un doute sur une clé, révoquez-la. Voir Sécurité et gestion des clés plus bas.
Conventions
Les champs de réponse sont en camelCase. Les paramètres de requête, eux, ne sont pas sensibles à la casse, donc le camelCase fonctionne là aussi — la spécification publiée les écrit en PascalCase, et c'est pour cela que vous verrez les deux formes circuler.
Un champ qui désigne un jour de calendrier est en YYYY-MM-DD. Un champ qui désigne 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. Demandez un pageSize de 500 et vous obtenez 100 lignes et un 200, pas une erreur — donc relisez pagination.pageSize dans la réponse plutôt que de vous fier à ce que vous avez envoyé.
Une réponse peut porter des champs que cette page ne liste pas. Ignorez ceux que vous ne reconnaissez pas plutôt que d'échouer dessus — c'est ce qui garde votre client fonctionnel à mesure que l'API s'étoffe.
REST, c'est du HTTP ordinaire, donc aucun SDK n'est nécessaire pour l'appeler — n'importe quel langage doté d'un client HTTP fait l'affaire. Il n'y a rien à installer.
Versionnage et changements
Tout ce qui est documenté ici relève de cette politique.
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.
Ce que nous pouvons changer sans préavis
Rien de tout cela ne casse un client qui suit les conventions ci-dessus.
Ajouter un point de terminaison, ou une opération sur un point existant.
Ajouter un champ à une réponse.
Ajouter un paramètre facultatif. Omettez-le et rien ne change.
Ajouter une valeur à un ensemble fixe, comme un statut ou un type.
Ajouter un en-tête de réponse.
Ce que nous ne changeons pas sans préavis
Chacun de ces changements peut casser un client qui fonctionne.
Retirer un point de terminaison, ou changer son chemin ou sa méthode.
Retirer ou renommer un champ de réponse.
Changer le type d'un champ ou sa signification.
Rendre obligatoire un paramètre aujourd'hui facultatif.
Refuser une entrée acceptée aujourd'hui.
Changer la portée dont un point de terminaison a besoin.
Avant chacun de ces changements, le changelog l'annonce au moins 90 jours à l'avance et vous dit quoi modifier. Ce qui fonctionne aujourd'hui continue de fonctionner jusque-là.
Les changements sont annoncés dans le changelog, dont le lien se trouve dans la section Changelog ci-dessous. Il n'y a pas encore d'e-mail ni de flux, alors consultez-le quand vous planifiez du travail sur l'API.
Tant que l'API est en bêta, l'ensemble documenté continuera de s'étoffer. Ce qui est déjà là ne cassera rien chez vous sans préavis.
Changelog
Les nouveautés de l'Era Developer Platform, dont l'API Era, du plus récent au plus ancien. La politique ci-dessus dit ce qui est annoncé à l'avance et avec quel délai ; le changelog est l'endroit où ces annonces paraissent.
Sécurité et gestion des clés
Approuver un agent crée une clé
Quand vous approuvez un agent en OAuth, Era lui crée une clé d'API. Elle arrive dans la même liste du tableau de bord que celles que vous créez vous-même, sous un nom qu'Era compose à partir du nom du client.
Comment elle est nommée
Auto -- ClaudeElle porte exactement les portées que vous avez approuvées sur cet écran, et rien d'autre. Révoquez-la depuis le tableau de bord et l'agent ne peut plus obtenir de nouvel accès tant que vous ne l'avez pas approuvé à nouveau. Un jeton qu'il détient déjà reste valable jusqu'à son expiration, une heure au plus.
Les écritures apparaissent dans votre journal d'activité, pas les lectures
La création et la révocation d'une clé apparaissent toutes les deux dans votre 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, vous ne voyez que les entrées les plus récentes. Même pour une écriture, REST ne tient aucun journal requête par requête : ce qui est noté, c'est le changement, pas l'appel, et il est inscrit sous votre compte, pas sous la clé qui l'a fait.
Si vous avez le moindre doute sur une clé, révoquez-la. Une clé que vous avez créée vous-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 prend une minute.
- Les portées sont larges
- banking:read couvre bien plus que les six lectures de cette page — la même portée couvre aussi le reste des lectures de votre compte : soldes, positions, connexions, dépenses. Une seule portée, il n'existe pas plus étroit. Les portées d'écriture sont au menu elles aussi, comme celles de lecture — alors traitez n'importe quelle clé comme un mot de passe. Elle agit au nom de votre compte, pas d'une partie de celui-ci. banking:write peut modifier des catégories, des étiquettes et les métadonnées d'une transaction, gérer des comptes et des soldes manuels, et connecter ou déconnecter des institutions — aucune portée de cette page ne peut déplacer de l'argent entre vos comptes bancaires.
- 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. C'est important pour tout ce qu'une portée couvre et qui n'est pas encore activé : accordez social:write aujourd'hui et la clé l'aura encore le jour où les vues partagées arriveront. Accordez ce que vous utilisez maintenant, pas ce que vous utiliserez peut-être.
- Aucune approbation requise
- Vous êtes déjà connecté à votre propre compte, donc créer une clé ne nécessite l'accord de personne d'autre — il n'y a ni examen ni liste d'attente, et personne chez Era n'approuve la demande. C'est inscrit dans votre journal d'activité dès sa création, donc une clé que vous ne reconnaissez pas est facile à repérer.
- Les identifiants bancaires restent hors de portée
- Une clé n'atteint pas vos identifiants bancaires, parce qu'Era ne les a jamais. Vous les saisissez dans le parcours 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, dont vous pouvez vous débarrasser en déconnectant l'établissement.
- Les clés sont hachées, pas stockées
- Votre clé, c'est 256 bits de données aléatoires, hachés en SHA-256 avant d'être stockés. Nous gardons le haché, pas la clé. Si vous la perdez, révoquez-la et créez-en une autre.
Ressources principales
Comptes
Tous les comptes que vous pouvez voir, dans chaque établissement connecté, avec à côté le nombre de ceux qui sont laissés de côté : excludedAccountCount, réparti entre tierExcludedAccountCount pour les comptes que la limite de comptes de votre forfait laisse de côté et userExcludedAccountCount pour ceux que vous avez masqués. accountLimit indique combien de comptes votre forfait affiche à la fois, toutes connexions confondues. accountLimitLift nomme le forfait le moins cher qui a de la place pour tous les comptes que vous n'avez pas masqués, et vaut null lorsque votre 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, c'est donc 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 votre forfait laisse de côté et ceux que vous avez masqués.
- connectionIdfacultatif
- Limite la liste aux comptes d'une seule connexion.
- includeExcludedfacultatif
- Inclut aussi les comptes que votre forfait laisse de côté et ceux que vous avez masqués, avec leurs soldes retenus. Le champ visibility de chaque ligne indique lequel — tierExcluded ou userExcluded, et visible pour les autres. Le point de terminaison de solde écrit ces valeurs autrement, n'utilisez donc pas le même analyseur pour les deux. excludedAccountCount revient malgré tout lorsque ce paramètre vaut true, et ces comptes figurent déjà dans la liste, n'additionnez donc 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 vous avez masqué ou que votre 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. Cela veut dire qu'Era ne peut pas se prononcer, jamais que la réponse est non. Il en va de même pour les champs du forfait. Si Era n'a pas pu lire votre forfait lors de cet appel, tierExcludedAccountCount, userExcludedAccountCount, accountLimit et accountLimitLift reviennent tous à null. accountLimit vaut aussi null pour un forfait sans limite de comptes, et accountLimitLift lorsqu'aucun forfait n'offre plus de place ou que votre 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é. Surveillez le champ visibility ici — il vaut null quand le compte est visible, tier_excluded quand la limite de comptes de votre forfait le laisse de côté, user_excluded quand vous l'avez masqué, et connection_severed quand sa connexion a été coupée. Avec tier_excluded, accountLimit est la limite de votre forfait et accountLimitLift nomme le forfait le moins cher qui a de la place pour tous les comptes que vous n'avez pas masqués, celui-ci compris. accountLimitLift vaut null dans tous les autres états, et avec connection_severed, accountLimit vaut null lui aussi.
Synthèse des comptes
Les totaux sur les comptes que vous pouvez voir — totalAssets, totalLiabilities et netWorthHint, qui est le premier moins le second. N'accepte aucun paramètre.
{
"userId": "7d1c0b93a8e24f60",
"accounts": [ … ],
"totalVisibleCount": 6,
"totalHiddenCount": 2,
"totalAssets": 48210.75,
"totalLiabilities": 9327.40,
"netWorthHint": 38883.35,
"computedAt": "2026-08-11T09:32:00Z"
}netWorthHint ne compte que les comptes présents dans cette réponse, donc totalHiddenCount vous dit ce qui lui manque — tierExcludedAccountCount d'entre eux sont laissés de côté par la limite de comptes de votre forfait, et userExcludedAccountCount sont ceux que vous avez masqués vous-même. accountLimitLift nomme le forfait le moins cher qui ramène les premiers, et vaut null lorsqu'il n'y en a aucun. Prenez netWorthHint comme un chiffre de départ plutôt que comme une valeur nette faisant autorité.
Transactions
Vos transactions, une page à la fois, dans une enveloppe qui porte les compteurs de pagination à côté. Accepte page et pageSize (100 au maximum), plus des filtres facultatifs par compte, plage de dates, règles appliquées et étiquettes assignées.
- accountIdfacultatif
- Limite aux transactions d'un compte, par son accountGroupKey.
- fromDatefacultatif
- Seulement les transactions à cette date ou après.
- toDatefacultatif
- Seulement les transactions à cette date ou avant.
- pagefacultatif
- Numéro de page, à partir de 1. Par défaut, 1.
- pageSizefacultatif
- Lignes par page. Par défaut, 50, plafonné à 100.
- sortByfacultatif
- Champ de tri : transactionDate, amount, description, category ou merchantName.
- sortDirectionfacultatif
- asc ou desc. Par défaut, décroissant.
- categoryKeysfacultatif
- 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.
- searchfacultatif
- Recherche plein texte sur le commerçant, la description, la catégorie, le nom du compte et le montant.
- ruleIdsfacultatif
- Seulement les transactions qu'une règle d'automatisation a touchées, par la clé de la règle.
- tagKeysfacultatif
- Seulement les transactions qui portent l'une de ces étiquettes.
- reviewStatusesfacultatif
- needs_review, reviewed ou flagged. Accepte une liste ; une transaction correspond si son statut de révision est l’un d’eux.
- includeChildrenfacultatif
- With a category filter set, also include transactions in the subcategories of every key you passed. Defaults to false.
- includePendingfacultatif
- Retourne aussi les opérations 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
}Votre forfait peut appliquer un plancher de fenêtre d'historique, qui masque les transactions plus anciennes que lui. C'est pour cela que la réponse porte les champs historyWindow : historyWindowApplied vous dit qu'un plancher a bel et bien masqué quelque chose, historyWindowFloorDate indique où il tombe, historyWindowHiddenCount combien de lignes se trouvent derrière, et historyWindowEarliestDate jusqu'où votre 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 vous écrivez : historyWindowHiddenCount peut valoir null même quand un plancher s'est appliqué, alors lisez null comme une valeur inconnue plutôt que comme un zéro. Et quand historyWindowDegraded vaut true, Era n'a pas pu confirmer votre 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 votre forfait laisse aussi des transactions de côté. tierExcludedAccountCount vous dit combien de vos comptes elle tient à l'écart de cette lecture, et userExcludedAccountCount combien vous en avez masqué — les deux limités au compte sur lequel vous filtrez, le cas échéant. Les deux valent null lorsqu'Era n'a pas pu lire votre forfait lors de cet appel.
Parcourir un long historique page par page consomme des requêtes. Votre forfait plafonne la vitesse à laquelle vous pouvez appeler et, sur le forfait gratuit, le nombre d'appels par jour. Limites donne les chiffres par forfait, les en-têtes de limite et ce que dit un 429.
Modifier une transaction
Quatre éléments d'une transaction peuvent être remplacés par les vôtres : sa catégorie, le nom du commerçant, une note personnelle et son statut de révision. N'envoyez que ceux que vous modifiez — tout ce que vous omettez reste tel quel. L'id dans le chemin est la clé utgr_ de la transaction. Cela modifie des données, il faut donc banking:write plutôt que banking:read.
- categoryKeyfacultatif
- La clé fcat_ de la catégorie à assigner. Omettez-la et la transaction garde la catégorie qu'elle a.
- merchantNamefacultatif
- Un nom de commerçant à vous, jusqu'à 1000 caractères. Omettez-le et le nom actuel reste inchangé.
- descriptionfacultatif
- Une note personnelle sur cette transaction, jusqu'à 5000 caractères. Omettez-la et la note actuelle reste inchangée.
- clearCategoryfacultatif
- Supprime votre substitution de catégorie, pour que la catégorisation propre à Era reprenne la main. Par défaut, false.
- clearMerchantNamefacultatif
- Supprime votre substitution de nom de commerçant, pour que le nom envoyé par votre banque revienne. Par défaut, false.
- clearDescriptionfacultatif
- Supprime votre substitution de description, pour que la description envoyée par votre banque revienne. Par défaut, false.
- reviewStatusfacultatif
- Marquez-la needs_review, reviewed ou flagged.
- clearReviewStatusfacultatif
- Supprime votre substitution de statut de révision. Par défaut, false.
{
"transaction": { … }
}Vous récupérez la transaction mise à jour en entier, dans la même forme que la liste ci-dessus — non reproduite ici, parce que c'est un objet volumineux encore en mouvement. Définir un champ et le réinitialiser dans le même appel renvoie 400. Une transaction qui n'est pas la vôtre, ou qui n'existe pas du tout, renvoie 403 — l'API ne fait pas la différence entre les deux. Et si autre chose a modifié la même ligne pendant que vous écriviez, vous obtenez 409 : relisez-la et renvoyez-la.
Modifier jusqu'à 100 à la fois
Les quatre mêmes substitutions, 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. Cela modifie des données, il faut donc banking:write plutôt que banking:read.
- transactionIds
- Les clés utgr_ des transactions à modifier. Au moins une, et pas plus de 100. Au-delà de 100, la requête est refusée plutôt que tronquée — contrairement à pageSize plus haut, vous obtenez un 400 et rien n'est modifié.
- categoryKeyfacultatif
- La clé fcat_ de la catégorie à assigner. Omettez-la et la transaction garde la catégorie qu'elle a.
- merchantNamefacultatif
- Un nom de commerçant à vous, jusqu'à 1000 caractères. Omettez-le et le nom actuel reste inchangé.
- descriptionfacultatif
- Une note personnelle sur cette transaction, jusqu'à 5000 caractères. Omettez-la et la note actuelle reste inchangée.
- clearCategoryfacultatif
- Supprime votre substitution de catégorie, pour que la catégorisation propre à Era reprenne la main. Par défaut, false.
- clearMerchantNamefacultatif
- Supprime votre substitution de nom de commerçant, pour que le nom envoyé par votre banque revienne. Par défaut, false.
- clearDescriptionfacultatif
- Supprime votre substitution de description, pour que la description envoyée par votre banque revienne. Par défaut, false.
- reviewStatusfacultatif
- Marquez-la needs_review, reviewed ou flagged.
- clearReviewStatusfacultatif
- Supprime votre substitution de statut de révision. Par défaut, false.
{
"transactions": [ … ]
}Vous récupérez les transactions mises à jour, dans la même forme que la liste ci-dessus. Définir un champ et le réinitialiser dans le même appel renvoie 400, tout comme une liste vide. Une liste contenant une transaction qui n'est pas la vôtre, ou qui n'existe pas du tout, renvoie 403 pour l'appel entier — rien n'est modifié. Si autre chose a modifié l'une de ces lignes pendant que vous écriviez, vous obtenez 409 : relisez-les et renvoyez-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. Cela modifie des données, il faut donc banking:write plutôt que banking:read.
- 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é.
- descriptionfacultatif
- Description facultative.
- iconNamefacultatif
- Nom d'icône facultatif.
- spendingTypefacultatif
- Classification de dépense facultative.
- displayOrderfacultatif
- Position de tri facultative parmi ses catégories sœurs.
- assignmentEligibilityfacultatif
- Règle facultative sur les transactions auxquelles cette catégorie peut être assignée.
- sourceSystemKeysfacultatif
- Liste facultative de clés de catégories existantes dont les transactions doivent être redirigées ici à partir de maintenant.
- applyRetroactivelyfacultatif
- 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 — des champs que cet appel partage avec les fusions de catégories, non montrés ici — ainsi qu'isQuotaExceeded, quotaExceededMessage et meterGate, qui valent toujours false, null et null sur une catégorie créée. Si le quota de votre forfait refuse la création, vous recevez plutôt un 402 sans aucun de ces champs. Son corps contient statusCode, message et errors.generalErrors, dont l'unique entrée vous indique quelle limite vous avez atteinte.
Étiquettes
Toutes les étiquettes de votre compte, en une seule liste. Pas de pagination — une seule réponse les renvoie toutes.
- tagTypefacultatif
- Filtre par origine de l'étiquette : user, system ou auto.
- includeDeletedfacultatif
- 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
A new tag, canonicalized to lowercase. Mutating, so it needs banking:write rather than banking:read. System tags cannot be created through the API; user and auto tags can.
- name
- Le nom canonique de l'étiquette.
- displayNamefacultatif
- Nom affiché facultatif. Par défaut, le nom canonique.
- tagTypefacultatif
- user or auto. Defaults to user. system is refused — it is reserved for tags Era creates itself.
- colorfacultatif
- Couleur hexadécimale facultative pour l'affichage.
- iconfacultatif
- Nom d'icône facultatif.
{
"tag": {
"tagKey": "utag_9c2f01ab",
"name": "business-expense",
"displayName": "Business expense",
"tagType": "user",
"version": 1,
"createdAt": "2026-08-26T09:15:00Z"
}
}