Era-API

Eine Transaktion ändern

Vier Dinge an einer Transaktion kannst du überschreiben: ihre Kategorie, den Händlernamen, eine eigene Notiz und ihren Prüfstatus. Schick nur die, die du änderst — was du weglässt, bleibt unverändert. Die id im Pfad ist der utgr_-Schlüssel der Transaktion. Dafür ist banking:write statt banking:read nötig, aber es ändert nur Eras Kopie der Transaktion: Die bei deiner Bank bleibt, wie sie war.

{
  "transaction": { … }
}

Du bekommst die gesamte aktualisierte Transaktion zurück, in derselben Form, die die Liste oben liefert — hier nicht erneut abgedruckt, weil es groß ist und sich ändert, solange die API in der Beta ist. Setzt du ein Feld und leerst es im selben Aufruf, kommt 400 zurück. Eine Transaktion, die dir nicht gehört, oder die es gar nicht gibt, kommt als 403 zurück — die API unterscheidet die beiden Fälle nicht. Und hat etwas anderes dieselbe Zeile geändert, während du geschrieben hast, bekommst du 409: lies sie erneut und schick sie erneut.

Bis zu 100 auf einmal ändern

Dieselben vier Überschreibungen, angewendet auf eine Liste von Transaktionen in einem Aufruf. Jede id in der Liste bekommt dieselben Änderungen — es gibt keine Variation pro Transaktion. Dafür ist banking:write statt banking:read nötig, aber es ändert nur Eras Kopien dieser Transaktionen: Die bei deiner Bank bleiben, wie sie waren.

{
  "transactions": [ … ]
}

Du bekommst die aktualisierten Transaktionen zurück, in derselben Form, die die Liste oben liefert. Setzt du ein Feld und leerst es im selben Aufruf, kommt 400 zurück, ebenso bei einer leeren Liste. Eine Liste, die eine Transaktion enthält, die dir nicht gehört oder die es gar nicht gibt, kommt für den gesamten Aufruf als 403 zurück — nichts wird geändert. Hat etwas anderes eine dieser Zeilen geändert, während du geschrieben hast, bekommst du 409: lies sie erneut und schick sie erneut.

Eine Kategorie anlegen

Eine benutzerdefinierte Kategorie unter einem bestehenden Elternteil. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Kategorien in Era: Bei deiner Bank ändert sich nichts.

{
  "categoryKey": "fcat_side_hustle_9f2a",
  "overlayProjectionKey": "fcov_9f2a1c",
  "action": "created",
  "isQuotaExceeded": false,
  "createdMappingRuleKeys": [ … ],
  …
}

Die Antwort trägt außerdem retroactiveAffectedCount, mergeSourcesHiddenCount und mergeSourcesTotalCount, die diese Seite nicht behandelt, sowie isQuotaExceeded, quotaExceededMessage und meterGate, die bei einer angelegten Kategorie immer false, null und null sind. Lehnt das Kontingent deines Tarifs die Neuanlage ab, kommt stattdessen ein 402 ohne diese Felder: Sein Body besteht aus statusCode, message und errors.generalErrors, dessen einziger Eintrag sagt, an welches Limit du gestoßen bist.

Einen Tag anlegen

Ein neuer Tag, in Kleinbuchstaben normalisiert. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Tags in Era: Bei deiner Bank ändert sich nichts. System-Tags lassen sich über die API nicht anlegen, user- und auto-Tags schon.

{
  "tag": {
    "tagKey": "utag_9c2f01ab",
    "name": "business-expense",
    "displayName": "Business expense",
    "tagType": "user",
    "version": 1,
    "createdAt": "2026-08-26T09:15:00Z"
  }
}

Eine Regel anlegen

Eine neue Automatisierungsregel: Bedingungen, die Transaktionen auswählen, und was mit jeder passiert, auf die sie zutreffen. Sie läuft ab dann bei jeder neuen Transaktion und, wenn du es willst, auch bei denen, die du schon hast. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Regeln und Transaktionen in Era: Bei deiner Bank ändert sich nichts.

{
  "rule": { … },
  "retroactiveStatus": "completed",
  "affectedTransactionCount": 18
}

retroactiveStatus ist null, außer du hast den Aufruf gebeten, die Regel auf Transaktionen anzuwenden, die du schon hast, oder rückgängig zu machen, was sie bewirkt hat. completed heißt, diese Arbeit war vor der Antwort fertig; in_progress heißt, sie läuft noch, affectedTransactionCount ist also noch nicht endgültig; queue_full heißt, die Warteschlange war voll und sie hat nicht begonnen — die Änderung an der Regel selbst wurde trotzdem gespeichert; partial_success heißt, nur ein Teil davon ist durchgegangen — manche Änderungen wurden nicht gespeichert, oder nur ein Teil der Arbeit wurde eingereiht.

Eine Regel vorab prüfen

Probiert die Bedingungen einer Regel an deinen letzten Transaktionen aus und meldet, worauf sie zutreffen würden, ohne etwas zu speichern: wie viele von den geprüften getroffen haben, bis zu 50 der Schlüssel der Treffer und bis zu 10 Stichproben. Eine Transaktionsregel prüft die letzten 90 Tage, höchstens 5.000 Transaktionen, und ihre Stichproben tragen Händler, Betrag und Datum. Die Stichproben einer Musterregel tragen detectionReason, warum das Muster erkannt wurde (das kann leer sein), und keinen Händler, Betrag oder Datum. Es wird nichts geschrieben, deshalb reicht banking:read.

{
  "matchCount": 12,
  "totalEvaluated": 418,
  "matchingGroupKeys": ["utgr_5d0e2b77", … ],
  "sampleMatches": [
    {
      "groupKey": "utgr_5d0e2b77",
      "merchantName": "Blue Bottle Coffee",
      "amount": -6.25,
      "currency": "USD",
      "transactionDate": "2026-09-12"
    },
    …
  ]
}

Eine Regel ändern

Ersetzt die Definition einer Regel durch die, die du schickst — schick also jedes Feld, das bleiben soll, nicht nur die, die du änderst. Die ruleId im Pfad ist die ID, die die Regelliste liefert, und version muss die sein, die du zuletzt gelesen hast. Bei einer Regel aus Eras Bibliothek kann sich nur userOverrides ändern: Schick alles andere so zurück, wie die Liste es geliefert hat. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Regeln und Transaktionen in Era: Bei deiner Bank ändert sich nichts.

{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

retroactiveStatus ist null, außer du hast den Aufruf gebeten, die Regel auf Transaktionen anzuwenden, die du schon hast, oder rückgängig zu machen, was sie bewirkt hat. completed heißt, diese Arbeit war vor der Antwort fertig; in_progress heißt, sie läuft noch, affectedTransactionCount ist also noch nicht endgültig; queue_full heißt, die Warteschlange war voll und sie hat nicht begonnen — die Änderung an der Regel selbst wurde trotzdem gespeichert; partial_success heißt, nur ein Teil davon ist durchgegangen — manche Änderungen wurden nicht gespeichert, oder nur ein Teil der Arbeit wurde eingereiht.

Eine Regel einschalten

Schaltet eine Regel wieder ein, sodass sie wieder bei neuen Transaktionen läuft. Eine Regel einzuschalten, die schon eingeschaltet ist, ändert nichts. Regeln aus Eras Bibliothek lassen sich wie deine eigenen ein- und ausschalten. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Regeln und Transaktionen in Era: Bei deiner Bank ändert sich nichts.

{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

Eine Regel ausschalten

Schaltet eine Regel aus, sodass sie bei neuen Transaktionen nicht mehr läuft. Sie behält ihre Definition, und was sie schon getan hat, bleibt, außer du forderst es mit revert_retroactively zurück. Eine Regel auszuschalten, die schon aus ist, lässt sie aus. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Regeln und Transaktionen in Era: Bei deiner Bank ändert sich nichts.

{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

retroactiveStatus ist null, außer du hast den Aufruf gebeten, die Regel auf Transaktionen anzuwenden, die du schon hast, oder rückgängig zu machen, was sie bewirkt hat. completed heißt, diese Arbeit war vor der Antwort fertig; in_progress heißt, sie läuft noch, affectedTransactionCount ist also noch nicht endgültig; queue_full heißt, die Warteschlange war voll und sie hat nicht begonnen — die Änderung an der Regel selbst wurde trotzdem gespeichert; partial_success heißt, nur ein Teil davon ist durchgegangen — manche Änderungen wurden nicht gespeichert, oder nur ein Teil der Arbeit wurde eingereiht.

Eine Regel löschen

Löscht eine Regel endgültig. Um eine Regel anzuhalten, ohne sie zu verlieren, schalte sie stattdessen aus. Die ruleId im Pfad ist die ID, die die Regelliste liefert, und version muss die sein, die du zuletzt gelesen hast. Regeln aus Eras Bibliothek lassen sich nicht löschen, nur ausschalten. Dafür ist banking:write statt banking:read nötig, aber es ändert nur deine Regeln und Transaktionen in Era: Bei deiner Bank ändert sich nichts. Ein Löschen mit revert_retroactively ist ein einziger Versuch: Kommt queue_full zurück, ist die Regel schon weg, und es bleibt nichts, woran sich ein neuer Versuch festmachen ließe. Um eine Regel zu löschen und rückgängig zu machen, was sie bewirkt hat, schalte sie zuerst mit revert_retroactively aus — das kannst du wiederholen, bis es angenommen wird — und lösche sie dann.

{
  "success": true,
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

retroactiveStatus ist null, außer du hast den Aufruf gebeten, die Regel auf Transaktionen anzuwenden, die du schon hast, oder rückgängig zu machen, was sie bewirkt hat. completed heißt, diese Arbeit war vor der Antwort fertig; in_progress heißt, sie läuft noch, affectedTransactionCount ist also noch nicht endgültig; queue_full heißt, die Warteschlange war voll und sie hat nicht begonnen — die Änderung an der Regel selbst wurde trotzdem gespeichert; partial_success heißt, nur ein Teil davon ist durchgegangen — manche Änderungen wurden nicht gespeichert, oder nur ein Teil der Arbeit wurde eingereiht.