Era-API

Einen Agenten freizugeben erzeugt einen Schlüssel

Wenn du einen Agenten per OAuth freigibst, erstellt Era ihm einen API-Schlüssel. Er landet in derselben Dashboard-Liste wie die, die du selbst anlegst, unter einem Namen, den Era aus dem Namen des Clients bildet.

Er trägt genau die Scopes, die du auf diesem Bildschirm freigegeben hast, und sonst nichts. Widerrufe ihn im Dashboard, und der Agent bekommt keinen neuen Zugriff, bis du ihn erneut freigibst. Ein Token, das er schon hat, funktioniert weiter, bis es abläuft — höchstens eine Stunde.

Schreibzugriffe stehen in deinem Aktivitätsprotokoll, Lesezugriffe nicht

Das Erstellen und das Widerrufen eines Schlüssels stehen beide in deinem Aktivitätsprotokoll, ebenso jeder Tool-Aufruf, den ein Agent über MCP macht. Ein REST-Schreibzugriff steht ebenfalls darin — als die Änderung, die er gemacht hat, etwa ein angelegter Tag oder eine bearbeitete Transaktion. Ein REST-Lesezugriff erzeugt überhaupt keinen Eintrag. Era schreibt diese Einträge in jedem Tarif mit, aber um das vollständige Protokoll zu lesen, brauchst du Organize oder höher — darunter siehst du nur die neuesten Einträge. Einträge zu einem Schreibzugriff nennen dein Konto, nicht den Schlüssel, der die Änderung gemacht hat.

Wenn du dir bei einem Schlüssel je unsicher bist, widerrufe ihn. Ein selbst erstellter Schlüssel funktioniert ab seiner nächsten Anfrage nicht mehr, auf REST wie auf MCP. Der Schlüssel eines Agenten bekommt sofort keinen neuen Zugriff mehr, und ein Token, das er schon hat, läuft innerhalb einer Stunde ab. Ein Ersatz ist in einer Minute erstellt.

Jedes Konto, das du sehen kannst, über alle verbundenen Banken hinweg, und daneben die Zahl der ausgelassenen: excludedAccountCount, aufgeteilt in tierExcludedAccountCount für die Konten, die das Live-Datenquellen-Limit deines Tarifs auslässt, und userExcludedAccountCount für die, die du ausgeblendet hast. accountLimit ist, wie viele Konten aus Live-Datenquellen dein Tarif gleichzeitig zeigt, über alle deine Verbindungen hinweg. Manuelle Konten zählen dabei nicht mit. accountLimitLift nennt den günstigsten Tarif, der Platz für jedes Konto aus Live-Datenquellen hat, das du nicht ausgeblendet hast, und ist null, wenn dein Tarif nichts auslässt. Jedes Konto trägt seinen accountGroupKey — den Wert, den der Salden-Endpunkt in seinem Pfad nimmt — und die connectionId, zu der es gehört, deshalb ist das der erste Aufruf. Nimmt connectionId, um auf eine einzelne Verbindung einzugrenzen (die Zahlen grenzen sich mit ein, accountLimit und accountLimitLift nicht), includeExcluded, um die Konten hereinzuholen, die dein Tarif auslässt, und die, die du ausgeblendet hast, und includeSevered, um die Konten von Verbindungen hereinzuholen, die du getrennt hast. Das Feld archive jedes Kontos sagt, ob es archiviert ist und warum; Archivieren ändert, wie ein Konto aufgeführt wird, nie einen Saldo oder eine Zahl.

{
  "accounts": [
    {
      "accountGroupKey": "uagr_7f3c9a21",
      "connectionId": "ucon_4b19e02c",
      "name": "Everyday Checking",
      "currentBalance": 4820.16,
      "supportsTransactions": true,
      …
    }
  ],
  "excludedAccountCount": 1
}

Ein Saldo, der als null zurückkommt, ist nie eine Null, und visibility sagt dir, was er bedeutet. Bei einem Konto, das du ausgeblendet hast (userExcluded) oder das dein Tarif ausschließt (tierExcluded), kommen die Saldenfelder als null zurück, weil der Saldo zurückgehalten wird, nicht weil er leer ist. Bei einem sichtbaren Konto heißt ein null bei currentBalance, dass der Anbieter nie einen Saldo gemeldet hat, und supportsBalances sagt, ob diese Art von Konto überhaupt einen Saldo meldet. Ein Saldo, den der Anbieter als Null gemeldet hat, kommt weiterhin als 0 zurück. supportsTransactions ist null im selben Sinn: Era kann es nicht sagen, und nie heißt es, die Antwort sei nein. Genauso bei den Tariffeldern: Wenn Era deinen Tarif bei dieser Anfrage nicht lesen konnte, kommen tierExcludedAccountCount, userExcludedAccountCount, accountLimit und accountLimitLift alle als null zurück. accountLimit ist außerdem null bei einem Tarif ohne Live-Datenquellen-Limit, und accountLimitLift, wenn kein Tarif mehr Platz hat oder dein Tarif nichts auslässt.

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
}

Ein ausgeblendetes Konto, oder eines, dessen Verbindung gekappt wurde, antwortet trotzdem mit 200 — mit den Saldenfeldern auf null. Ein 404 heißt, dass es das Konto wirklich nicht gibt oder der Schlüssel nicht die Form eines Schlüssels hatte. Achte hier auf das Feld visibility: Es ist null, wenn das Konto sichtbar ist, tier_excluded, wenn das Limit deines Tarifs es auslässt, user_excluded, wenn du es ausgeblendet hast, und connection_severed, wenn seine Verbindung gekappt wurde. Bei einem tier_excluded-Konto aus einer Live-Datenquelle ist accountLimit das Live-Datenquellen-Limit deines Tarifs, und accountLimitLift nennt den günstigsten Tarif, der Platz für jedes solche Konto hat, das du nicht ausgeblendet hast, dieses eingeschlossen. Bei einem manuellen Konto und bei jedem anderen Zustand ist accountLimitLift null, und bei connection_severed ist auch accountLimit null. Bei einem sichtbaren Konto (visibility ist null) heißt ein null bei currentBalance, dass kein Saldo gemeldet wurde, nie eine Null. supportsBalances in der Zeile des Kontos in der Kontenliste sagt, ob diese Art von Konto überhaupt einen Saldo meldet.

Summen über die Konten, die du sehen kannst, standardmäßig die Live-Konten: totalAssets, totalLiabilities und netWorthHint, also das erste minus dem zweiten. Mit simulationModes legst du fest, welche Modi zählen: Die Kontenliste und die Summen decken nur die ab, die du nennst. includedSimulationModes nennt in jeder Antwort, welche Modi sie abdecken. simulationExcludedAccountCount zählt die Konten, die du sehen kannst und die wegen ihres Modus ausgelassen wurden. totalHiddenCount ist eine eigene Zahl: die Konten, die dein Tarif oder deine eigene Sichtbarkeitseinstellung ausblendet, in jedem Modus, und nie die, die simulationModes ausgelassen hat.

{
  "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 zählt nur die Konten in dieser Antwort, und zwei Zahlen sagen dir, was er auslässt. simulationExcludedAccountCount sind die Konten außerhalb der Modi, die du angefragt hast. totalHiddenCount sind die Konten, die dir in jedem Modus ausgeblendet sind. Die Zahl teilt sich in zwei: tierExcludedAccountCount für die, die das Live-Datenquellen-Limit deines Tarifs auslässt, und userExcludedAccountCount für die, die du selbst ausgeblendet hast. Beide sind null, wenn Era deinen Tarif bei diesem Aufruf nicht lesen konnte. accountLimitLift nennt den günstigsten Tarif, der die erste Sorte zurückholt, und ist null, wenn es keine gibt. Ein Konto, dessen Saldo nicht gemeldet wurde, steht trotzdem in der Liste, trägt aber nichts zu den Summen bei. Nimm netWorthHint als Ausgangszahl und nicht als verbindliches Nettovermögen.

Deine Transaktionen, seitenweise, eingepackt zusammen mit den Seitenzahlen. Nimmt page und pageSize (100 ist die Obergrenze), dazu optionale Filter nach Konto, Zeitraum, angewendeten Regeln und vergebenen Tags.

{
  "transactions": [ … ],
  "pagination": {
    "currentPage": 1,
    "pageSize": 20,
    "totalItems": 412,
    "totalPages": 21
  },
  "historyWindowApplied": true,
  "historyWindowFloorDate": "2026-06-28",
  "historyWindowHiddenCount": 137,
  "historyWindowEarliestDate": "2024-03-02",
  "historyWindowDegraded": false
}

Es gibt keinen Aufruf, der eine einzelne Transaktion über ihre id liest. GET /banking/transactions/{id} antwortet mit 405 und Allow: PUT, weil dieser Pfad eine Transaktion nur ändert. Um eine zu lesen, ruf die Liste mit Filtern auf, die sie eingrenzen — accountId auf ihren accountGroupKey, fromDate und toDate beide auf ihr transactionDate und search auf ihren Händlernamen oder Betrag — und such sie dann anhand ihrer id aus dem heraus, was zurückkommt. Ist es eine aktuelle vorgemerkte Belastung, gib zusätzlich includePending mit.

Dein Tarif kann eine Verlaufsfenster-Grenze anwenden, die ältere Transaktionen verbirgt. Deshalb trägt die Antwort die historyWindow-Felder: historyWindowApplied sagt dir, dass eine Grenze tatsächlich etwas verborgen hat, historyWindowFloorDate, wo sie liegt, historyWindowHiddenCount, wie viele Zeilen dahinter stehen, und historyWindowEarliestDate, wie weit dein Verlauf wirklich zurückreicht. Ohne sie ist ein kurzes Ergebnis nicht von einem Konto ohne ältere Transaktionen zu unterscheiden. Zwei davon ändern, was du schreibst: historyWindowHiddenCount kann null sein, auch wenn eine Grenze gegriffen hat — lies null also als unbekannt und nicht als die Zahl 0; und wenn historyWindowDegraded true ist, konnte Era deinen Tarif bei dieser Anfrage nicht bestätigen, das Grenzdatum ist dann eine Schätzung und keine Tatsache. Bei einer bestätigten bezahlten Anfrage greift keine Grenze, und historyWindowApplied kommt als false zurück. Auch das Live-Datenquellen-Limit deines Tarifs lässt Transaktionen aus: tierExcludedAccountCount sagt, wie viele deiner Konten es aus dieser Anfrage heraushält, und userExcludedAccountCount, wie viele du ausgeblendet hast — beide auf das Konto eingegrenzt, nach dem du gefiltert hast, falls du das getan hast. Beide sind null, wenn Era deinen Tarif bei dieser Anfrage nicht lesen konnte.

Durch eine lange Historie zu blättern verbraucht Anfragen. Dein Tarif begrenzt, wie schnell du aufrufen kannst, und im kostenlosen Tarif, wie viele Aufrufe du pro Tag bekommst; bezahlte Tarife laufen unter fairer Nutzung. Unter Limits stehen die Zahlen pro Tarif, die Rate-Limit-Header und was ein 429 dir sagt.

Die gesamte Kategorien-Taxonomie: jede Kategoriengruppe, mit ihren Unterkategorien darin verschachtelt. Die Taxonomie ist gemeinsam, nicht pro Konto.

{
  "packs": [
    {
      "packSlug": "default",
      "packName": "Era default categories",
      "isDefault": true,
      "categories": [
        {
          "projectionKey": "fcat_food_dining",
          "categoryName": "Food & dining",
          "isTopLevel": true,
          "children": [ … ]
        }
      ]
    }
  ],
  "meterLimit": 25,
  "canCreateCustomCategories": true
}

Alle Tags deines Kontos, als eine Liste. Keine Seitenaufteilung — eine Antwort gibt dir alle zurück.

{
  "tags": [
    {
      "tagKey": "ftag_3fG7kL9p",
      "name": "business-expense",
      "displayName": "Business expense",
      "tagType": "user",
      "color": "#6DC6BA",
      "transactionCount": 42
    }
  ]
}

Die Zahlungen, Rechnungen und Einnahmen, die sich in deinen Transaktionen wiederholen, nach estimatedAmount absteigend sortiert. Die Liste kommt aus einer von zwei Quellen. Sobald Era in deinen Transaktionen wiederkehrende Muster erkannt hat, listet sie diese auf, jeweils mit confidence system. Bis dahin gruppiert sie die jüngeren Transaktionen, die die Daten deiner Bank als wiederkehrend, als Abo, als Rechnungszahlung oder als Einnahme kennzeichnen, nach Händler und Währung, jede Gruppe mit confidence provider. Jeder Eintrag hat den merchant; estimatedAmount, den typischen Betrag pro Mal, nie negativ, egal in welche Richtung das Geld fließt; frequency, Eras Schätzung, wie oft er sich wiederholt; category, die null ist, wenn es keine gibt, und bei einem von Era erkannten Muster immer null; lastSeen, das Datum der letzten Transaktion oder, bei einem von Era erkannten Muster, das Datum, an dem Era es erkannt hat; type; und confidence. type ist subscription, bill oder income, wo die Daten deiner Bank das angeben, und recurring, wo nicht — das gilt für jedes von Era erkannte Muster. Bei einem Eintrag mit type recurring sagt also nichts, ob das Geld hereinkommt oder hinausgeht. Ausstehende Buchungen sind nicht enthalten. Nimmt keine Parameter und ignoriert alle, die du sendest.

{
  "items": [
    {
      "merchant": "Netflix",
      "estimatedAmount": { "amount": 15.49, "currency": "usd", … },
      "frequency": "monthly",
      "category": "Entertainment",
      "lastSeen": "2026-09-28",
      "type": "subscription",
      "confidence": "provider"
    },
    …
  ]
}

Einnahmen und Ausgaben in einem Zeitraum: income, expense und net, also das Erste minus das Zweite, mit den Kategorien hinter jeder Seite — incomeCategories und expenseCategories, die größte zuerst, jede mit ihrem Betrag, ihrem Anteil an der Summe dieser Seite und der Zahl der Transaktionen darin. Überweisungen zwischen deinen Konten, ausstehende Buchungen und Transaktionen, die du ausgeblendet hast oder die auf Konten liegen, die du ausgeblendet hast oder die das Live-Datenquellen-Limit deines Tarifs auslässt, sind nicht enthalten; excludedAccountCount zählt diese Konten. income und expense zählen jede Kategorie ihrer Seite, auch die, die topN von der Liste lässt, deshalb können die zurückgegebenen Kategorien zusammen weniger ergeben als die Summe ihrer Seite; jeder percentOfTotal ist ein Anteil an dieser vollen Summe. Der angefragte Zeitraum kommt mit Anfang, Ende und einer lesbaren Bezeichnung zurück. Ist incomePercentOfTotalUnavailable oder expensePercentOfTotalUnavailable true, sind die percentOfTotal-Werte dieser Seite 0, weil sich der Anteil nicht berechnen ließ, nicht weil die Kategorie 0 % davon ausmacht — lies sie als fehlend. Standardmäßig der aktuelle Monat.

{
  "period": { "period": "last_month", "start": "2026-09-01", "end": "2026-09-30", "label": "September 2026" },
  "income": { "amount": 5200.00, "currency": "usd", … },
  "expense": { "amount": 4000.00, "currency": "usd", … },
  "net": { "amount": 1200.00, "currency": "usd", … },
  "incomeCategories": [ … ],
  "expenseCategories": [
    {
      "label": "Groceries",
      "categoryKey": "fcat_groceries",
      "amount": { "amount": 600.00, "currency": "usd", … },
      "percentOfTotal": 15,
      "transactionCount": 14,
      "children": null
    },
    …
  ],
  "excludedAccountCount": 0,
  "excludedAccountNote": null,
  "incomePercentOfTotalUnavailable": false,
  "expensePercentOfTotalUnavailable": false
}

Alle Automatisierungsregeln deines Kontos — die, die du selbst angelegt hast, und die, die Era dir aus seiner Regelbibliothek eingerichtet hat — jeweils mit ihren Bedingungen (filters), dem, was sie tun (actions), ob sie eingeschaltet sind, und ihrer Version. Keine Seitenaufteilung: Eine Antwort gibt dir alle zurück. Ausgeschaltete Regeln fehlen, außer du fragst nach ihnen.

{
  "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 und actions sind Listen typisierter Objekte. Jedes nennt seine Art in einem type-Feld — merchant_match oder category bei den Filtern, set_category oder add_tag bei den Aktionen —, und das im Schnellstart verlinkte OpenAPI-Dokument listet jede Art mit den Feldern, die sie nimmt.