Schnellstart
Bevor du loslegst, brauchst du ein Era-Konto mit mindestens einer verbundenen Bank — ohne Verbindung haben diese Endpunkte nichts zurückzugeben.
- 1
Melde dich bei Era an und verbinde eine Bank, falls noch nicht geschehen.
- 2
Öffne deine API-Schlüssel im Dashboard und erstell einen. Alle Scopes sind vorab angehakt, also hak die ab, die du nicht brauchst — für diese Endpunkte bleibt banking:read übrig. Du wählst außerdem eine Gültigkeitsdauer; eine Option „läuft nie ab“ gibt es nicht.
- 3
Kopier den Schlüssel. Er wird einmal angezeigt, und wir können ihn nicht erneut zeigen. Kopier ihn und bewahr ihn an einem sicheren Ort auf, zum Beispiel in einem Secrets-Manager. Verlierst du einen Schlüssel, kannst du ihn nicht erneut einsehen. Leg stattdessen einen neuen an.
- 4
Schick ihn mit deinem Request im Header mit.
cURL
curl "https://forge.era.app/api/banking/transactions?page=1&pageSize=20" \
-H "X-API-Key: fmk_your_key_here"
Antwort · 200
{
"transactions": [ … ],
"pagination": {
"currentPage": 1,
"pageSize": 20,
"totalItems": 412,
"totalPages": 21
},
"historyWindowApplied": true,
"historyWindowFloorDate": "2026-06-28",
"historyWindowHiddenCount": 137,
"historyWindowEarliestDate": "2024-03-02",
"historyWindowDegraded": false
}
Verfügbare APIs
Die Era-API umfasst die folgenden APIs:
- GET/banking/accounts
Jedes Konto, das du sehen kannst, über alle verbundenen Institute hinweg.
- GET/banking/accounts/{accountId}/balance
Der Saldo eines Kontos, inklusive Kreditfelder bei einer Verbindlichkeit.
- GET/banking/accounts/summary
Summen über alle Konten, die du sehen kannst.
- GET/banking/transactions
Deine Transaktionen, seitenweise.
- PUT/banking/transactions/{id}
Eine Transaktion ändern
- PUT/banking/transactions/bulk
Bis zu 100 auf einmal ändern
- GET/banking/categories
Die gesamte Kategorie-Taxonomie, mit verschachtelten Unterkategorien.
- POST/banking/categories
Eine Kategorie anlegen
- GET/banking/tags
Alle Tags deines Kontos, in einer Antwort.
- POST/banking/tags
Einen Tag anlegen
Authentifizierung
Sende deinen Schlüssel auf eine von zwei Arten:
| Methode | Anmeldedaten |
|---|---|
| Header | X-API-Key: fmk_your_key_here |
| Bearer-Token | Authorization: Bearer fmk_your_key_here |
Jeder Request ist TLS-verschlüsselt.
Schlüssel laufen ab, und du wählst beim Erstellen, wie bald. Das Maximum sind 90 Tage im kostenlosen Tarif und 365 in einem bezahlten — eine Option „läuft nie ab“ existiert nicht, also braucht alles, was du darauf baust, einen Plan zum Rotieren des Schlüssels, bevor er verfällt.
Antwort-Header
Jede Antwort enthält:
| Header | Beschreibung |
|---|---|
| fly-request-id | Eine eindeutige Kennung für die Anfrage. Gib sie an, wenn du den Support zu einer bestimmten Anfrage kontaktierst — siehe Request-ID |
Fehler
Die API liefert diese Fehler-Statuscodes:
- 400
Fehlerhafte Eingabe: ein falscher Parameter, ein leeres oder über 100 Einträge großes Bulk-Update, oder ein Schreibzugriff, der dasselbe Feld im selben Aufruf setzt und löscht.
- 401
Kein Schlüssel, oder einer, der sich nicht parsen lässt. Sende ihn als X-API-Key-Header oder als Bearer-Token.
- 402
Ein Plan-Kontingent steht im Weg — heute betrifft das nur das Anlegen von Kategorien.
- 403
Der Schlüssel trägt nicht den Scope, den dieser Aufruf braucht — oder, bei einem der beiden Transaktions-Schreibzugriffe, die ID gehört jemand anderem oder existiert gar nicht. Die API unterscheidet die beiden Fälle nicht.
- 409
Etwas anderes hat die Zeile geändert, während du geschrieben hast. Lies sie erneut und schreibe erneut.
Fehlerformen
Jeder Fehler kommt in derselben Form zurück — statusCode, message und ein errors-Objekt, das benennt, was falsch war. Ein fehlender oder ungültiger Schlüssel kann auch ganz ohne Body zurückkommen.
Beispiel
{
"statusCode": 403,
"message": "One or more errors occurred!",
"errors": {
"generalErrors": ["Transaction does not belong to the authenticated user"]
}
}
Request-ID
Jede Antwort trägt einen fly-request-id-Header. Gib ihn an, wenn du den Support zu einer bestimmten Anfrage kontaktierst.
cURL
# 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"
cURL (Schreibvorgang)
# 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"}'
Häufige Fehler
Ein Feld im selben Schreibzugriff setzen und löschen — 400.
Mehr als 100 IDs in einem Bulk-Update — 400, und nichts wird geändert. Weniger als eine ID ist genauso.
Eine Transaktion, die nicht dir gehört oder gar nicht existiert — 403, niemals 404. Die Antwort verrät also nie, ob eine ID überhaupt existiert, nur dass sie nicht dir gehört.
Etwas anderes hat die Zeile zuerst geändert — 409.
Limits
Zwei der zehn dokumentierten Endpunkte begrenzen, wie viel du in einem Aufruf anfordern kannst. Die anderen acht nicht.
Das heißt nicht unbegrenzt: Schlüssel laufen weiterhin ab, Schreibvorgänge haben weiterhin Feldlängenbegrenzungen, und dein Tarif kann weiterhin älteren Verlauf ausblenden. Nichts davon ist ein Rate Limit — siehe unten.
Konten, Kontostand, Übersicht, Kategorien, Tags und das Schreiben einzelner Transaktionen haben kein Volumenlimit pro Aufruf. Du bekommst entweder die gesamte Menge zurück oder genau die eine Zeile, die du benannt hast.
pageSize wird auf 100 gekappt, nicht abgelehnt. Fordere mehr an, und du bekommst 100 Zeilen mit einem 200 zurück — lies pagination.pageSize aus der Antwort, statt dem zu vertrauen, was du gesendet hast.
Der Bulk-Schreibzugriff für Transaktionen ist auf 100 IDs gedeckelt, und anders als pageSize wird er abgelehnt statt gekappt: Sende 101, und du bekommst einen 400, und nichts ändert sich.
Schlüssel laufen nach einem Zeitplan ab, den du bei der Erstellung wählst — bis zu 90 Tage im kostenlosen Plan, 365 in einem bezahlten. Es gibt keine Option, die nie abläuft.
Dein Plan kann eine Verlaufsfenster-Untergrenze setzen, die ältere Transaktionen verbirgt. Die Transaktions-Antwort trägt die historyWindow-Felder, die dir sagen, ob eine galt und wo sie lag.
Pläne nennen auch ein API-Anfrage-Kontingent — 500 im kostenlosen Plan, mehr in jedem bezahlten.
Was hier fehlt: Es gibt heute keine Drosselung pro Anfrage auf REST, keinen 429, und keine Rate-Limit-Header — ein gestohlener Schlüssel wird also von nichts auf unserer Seite gebremst. Wenn du dir bei einem Schlüssel je unsicher bist, widerrufe ihn: das kappt ihn sofort (siehe Sicherheit und Schlüsselverwaltung oben). Und nimm, weil diese API in der Beta ist, nicht an, dass das so bleibt.
Konventionen
Antwortfelder sind camelCase. Bei Query-Parametern spielt die Groß- und Kleinschreibung keine Rolle, camelCase funktioniert dort also ebenfalls — die veröffentlichte Spezifikation schreibt sie PascalCase, deshalb begegnen dir beide Formen.
Ein Feld, das einen Kalendertag nennt, ist YYYY-MM-DD. Ein Feld, das einen Zeitpunkt nennt, ist ISO 8601 mit Zeitzonenversatz.
Seitengrößen werden gekappt, nicht abgelehnt. Frag ein pageSize von 500 an, und du bekommst 100 Zeilen und ein 200, keinen Fehler — lies pagination.pageSize also aus der Antwort zurück, statt dich auf das zu verlassen, was du geschickt hast.
Eine Antwort kann Felder tragen, die diese Seite nicht aufführt. Ignorier die, die du nicht kennst, statt daran zu scheitern — das hält deinen Client am Laufen, während die API wächst.
REST ist schlichtes HTTP, für den Aufruf braucht es also kein SDK — jede Sprache mit einem HTTP-Client reicht aus. Es gibt nichts zu installieren.
Sicherheit und Schlüsselverwaltung
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.
Wie er heißt
Auto -- ClaudeEr trägt genau die Scopes, die du auf diesem Bildschirm freigegeben hast, und sonst nichts. Widerrufe ihn im Dashboard, und der Agent erreicht dein Konto nicht mehr, bis du ihn erneut freigibst.
Schlichte REST-Aufrufe werden nicht protokolliert
Das Erstellen und das Widerrufen eines Schlüssels stehen beide in deinem Aktivitätsprotokoll, ebenso jeder Tool-Aufruf, den ein Agent über MCP macht. Einzelne REST-Aufrufe nicht — ob Lese- oder Schreibzugriff, auf diesem Weg gibt es heute kein Protokoll pro Request.
Wenn du dir bei einem Schlüssel je unsicher bist, widerruf ihn. Der Widerruf wirkt sofort, schneidet den Schlüssel auf REST und MCP ab, und ein Ersatz kostet dich eine Minute.
| Fakt | Was das bedeutet |
|---|---|
| Scopes sind grob | banking:read deckt weit mehr ab als die sechs Lesezugriffe auf dieser Seite — derselbe Scope deckt auch alle übrigen Lesezugriffe deines Kontos ab: Salden, Positionen, Verbindungen, Ausgaben. Ein Scope, enger geht es nicht. Schreib-Scopes stehen ebenfalls zur Auswahl — behandle also jeden Schlüssel wie ein Passwort. Er handelt als dein Konto, nicht nur als ein Ausschnitt davon. banking:write kann Kategorien, Tags und Transaktions-Metadaten ändern, manuelle Konten und Salden verwalten und Institute verbinden oder trennen — kein Scope auf dieser Seite kann Geld zwischen deinen Bankkonten bewegen. |
| Scopes aktualisieren sich nicht | Die Scopes eines Schlüssels stehen beim Erstellen fest und ändern sich danach nie. Das ist für alles wichtig, was ein Scope abdeckt und noch nicht aktiviert ist: gib social:write heute frei, und der Schlüssel hat ihn auch dann noch, wenn es geteilte Ansichten gibt. Gib frei, was du jetzt nutzt, nicht was du vielleicht nutzen wirst. |
| Keine Freigabe nötig | Du bist bereits in deinem eigenen Konto angemeldet, deshalb braucht das Erstellen eines Schlüssels keine fremde Zustimmung — es gibt keine Prüfung und keine Warteliste, und niemand bei Era gibt die Anfrage frei. Es wird sofort in dein Aktivitätsprotokoll geschrieben, sodass ein unbekannter Schlüssel leicht auffällt. |
| Bank-Login bleibt unerreichbar | Ein Schlüssel erreicht dein Bank-Login nicht, weil Era es nie hat. Du gibst es in der Verbindungsstrecke des Datenanbieters ein, nicht auf einem Era-Bildschirm — was Era danach behält, ist ein mit AES-256 verschlüsseltes Zugriffstoken pro Verbindung, das du durch Trennen der Bank wegwerfen kannst. |
| Schlüssel werden gehasht, nicht gespeichert | Dein Schlüssel besteht aus 256 Bit Zufallsdaten und wird vor dem Speichern mit SHA-256 gehasht. Wir behalten den Hash, nicht den Schlüssel. Verlierst du ihn, widerrufst du ihn und erstellst einen neuen. |
Kernressourcen
Konten
Erforderlicher Scope
banking:readJedes Konto, das du sehen kannst, über alle verbundenen Banken hinweg, und daneben die Zahl der ausgelassenen. 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, und includeExcluded, um Konten hereinzuholen, die du ausgeblendet hast.
connectionIdoptional | Grenzt die Liste auf die Konten einer Verbindung ein. |
|---|---|
includeExcludedoptional | Bezieht auch tier-ausgeschlossene und ausgeblendete Konten mit ein, mit verschleierten Salden. Standardmäßig false. |
Antwort · 200
{
"accounts": [
{
"accountGroupKey": "uagr_7f3c9a21",
"connectionId": "ucon_4b19e02c",
"name": "Everyday Checking",
"currentBalance": 4820.16,
"supportsTransactions": true,
…
}
],
"excludedAccountCount": 1
}
Bei einem Konto, das du ausgeblendet hast oder das dein Tarif ausschließt, kommen die Saldenfelder als null zurück und nicht als Null — null heißt zurückgehalten, nicht leer. supportsTransactions ist null im selben Sinn: Era kann es nicht sagen, und nie heißt es, die Antwort sei nein.
Kontosaldo
Erforderlicher Scope
banking:readDer Saldo eines einzelnen Kontos, mit den Kreditfeldern gefüllt, wenn das Konto eine Verbindlichkeit ist. Der Pfad nimmt den accountGroupKey dieses Kontos — denselben Wert, den /banking/accounts dafür zurückgibt. Ein Schlüssel in einer anderen Form wird abgewiesen, bevor die Suche überhaupt läuft.
Antwort · 200
{
"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. Nur ein Konto, das es wirklich nicht gibt, gibt dir ein 404. Achte hier auf das Feld visibility: Es ist null, wenn das Konto sichtbar ist, und eine Zeichenfolge wie tier_excluded, wenn nicht.
Kontoübersicht
Erforderlicher Scope
banking:readSummen über die Konten, die du sehen kannst: totalAssets, totalLiabilities und netWorthHint, also das erste minus dem zweiten. Nimmt keine Parameter.
Antwort · 200
{
"userId": "7d1c0b93a8e24f60",
"accounts": [ … ],
"totalVisibleCount": 6,
"totalHiddenCount": 2,
"totalAssets": 48210.75,
"totalLiabilities": 9327.40,
"netWorthHint": 38883.35,
"computedAt": "2026-08-11T09:32:00Z"
}
netWorthHint zählt nur die Konten in dieser Antwort, deshalb sagt dir totalHiddenCount, was ihm fehlt. Nimm es als Ausgangszahl und nicht als verbindliches Nettovermögen.
Transaktionen
Erforderlicher Scope
banking:readDeine 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.
accountIdoptional | Grenzt auf die Transaktionen eines Kontos ein, über dessen accountGroupKey. |
|---|---|
fromDateoptional | Nur Transaktionen an oder nach diesem Datum. |
toDateoptional | Nur Transaktionen an oder vor diesem Datum. |
pageoptional | Seitenzahl, ab 1 gezählt. Standardmäßig 1. |
pageSizeoptional | Zeilen pro Seite. Standardmäßig 50, auf 100 begrenzt. |
sortByoptional | Feld für die Sortierung: transactionDate, amount, description, category oder merchantName. |
sortDirectionoptional | asc oder desc. Standardmäßig absteigend. |
categoryKeyoptional | Nur Transaktionen einer Kategorie, über deren fcat_-Schlüssel. |
searchoptional | Volltextsuche über Händler, Beschreibung, Kategorie, Kontoname und Betrag. |
ruleIdsoptional | Nur Transaktionen, die eine Automatisierungsregel berührt hat, über den Schlüssel der Regel. |
tagKeysoptional | Nur Transaktionen mit einem dieser Tags. |
reviewStatusoptional | needs_review, reviewed oder flagged. |
includeChildrenoptional | Bezieht bei gesetztem categoryKey auch dessen Unterkategorien mit ein. Standardmäßig false. |
Antwort · 200
{
"transactions": [ … ],
"pagination": {
"currentPage": 1,
"pageSize": 20,
"totalItems": 412,
"totalPages": 21
},
"historyWindowApplied": true,
"historyWindowFloorDate": "2026-06-28",
"historyWindowHiddenCount": 137,
"historyWindowEarliestDate": "2024-03-02",
"historyWindowDegraded": false
}
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.
Tarife nennen außerdem ein Kontingent an API-Anfragen — 500 im kostenlosen, mehr in jedem bezahlten. Die aktuellen Zahlen stehen bei den übrigen Grenzen deines Tarifs.
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. Verändert Daten, deshalb ist banking:write statt banking:read nötig.
Erforderlicher Scope
banking:writecategoryKeyoptional | Der fcat_-Schlüssel der zuzuweisenden Kategorie. Lässt du ihn weg, behält die Transaktion ihre bisherige Kategorie. |
|---|---|
merchantNameoptional | Ein eigener Händlername, bis zu 1000 Zeichen. Lässt du ihn weg, bleibt der aktuelle Name bestehen. |
descriptionoptional | Eine eigene Notiz zu dieser Transaktion, bis zu 5000 Zeichen. Lässt du sie weg, bleibt die aktuelle Notiz bestehen. |
reviewStatusoptional | Markiert sie als needs_review, reviewed oder flagged. |
clearCategoryoptional | Verwirft deine Kategorie-Überschreibung, sodass Eras eigene Kategorisierung wieder greift. Standardmäßig false. |
clearMerchantNameoptional | Verwirft deine Überschreibung des Händlernamens, sodass der von deiner Bank gesendete Name zurückkehrt. Standardmäßig false. |
clearDescriptionoptional | Verwirft deine Beschreibungs-Überschreibung, sodass die von deiner Bank gesendete Beschreibung zurückkehrt. Standardmäßig false. |
clearReviewStatusoptional | Verwirft deine Überschreibung des Prüfstatus. Standardmäßig false. |
Antwort · 200
{
"transaction": { … }
}
Du bekommst die gesamte aktualisierte Transaktion zurück, in derselben Form, die die Liste oben liefert — hier nicht erneut abgedruckt, weil es ein großes Objekt ist, das sich noch verändert. 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. Verändert Daten, deshalb ist banking:write statt banking:read nötig.
Erforderlicher Scope
banking:writetransactionIds | Die utgr_-Schlüssel der zu ändernden Transaktionen. Mindestens einer, höchstens 100. Über 100 wird abgelehnt statt gekappt — anders als pageSize oben bekommst du ein 400, und es ändert sich gar nichts. |
|---|---|
categoryKeyoptional | Der fcat_-Schlüssel der zuzuweisenden Kategorie. Lässt du ihn weg, behält die Transaktion ihre bisherige Kategorie. |
merchantNameoptional | Ein eigener Händlername, bis zu 1000 Zeichen. Lässt du ihn weg, bleibt der aktuelle Name bestehen. |
descriptionoptional | Eine eigene Notiz zu dieser Transaktion, bis zu 5000 Zeichen. Lässt du sie weg, bleibt die aktuelle Notiz bestehen. |
reviewStatusoptional | Markiert sie als needs_review, reviewed oder flagged. |
clearCategoryoptional | Verwirft deine Kategorie-Überschreibung, sodass Eras eigene Kategorisierung wieder greift. Standardmäßig false. |
clearMerchantNameoptional | Verwirft deine Überschreibung des Händlernamens, sodass der von deiner Bank gesendete Name zurückkehrt. Standardmäßig false. |
clearDescriptionoptional | Verwirft deine Beschreibungs-Überschreibung, sodass die von deiner Bank gesendete Beschreibung zurückkehrt. Standardmäßig false. |
clearReviewStatusoptional | Verwirft deine Überschreibung des Prüfstatus. Standardmäßig false. |
Antwort · 200
{
"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.
Kategorien
Erforderlicher Scope
banking:readDie gesamte Kategorien-Taxonomie: jede Kategoriengruppe, mit ihren Unterkategorien darin verschachtelt. Die Taxonomie ist gemeinsam, nicht pro Konto.
Antwort · 200
{
"packs": [
{
"packSlug": "default",
"packName": "Era default categories",
"isDefault": true,
"categories": [
{
"projectionKey": "fcat_food_dining",
"categoryName": "Food & dining",
"isTopLevel": true,
"children": [ … ]
}
]
}
],
"meterLimit": 25,
"canCreateCustomCategories": true
}
Eine Kategorie anlegen
Eine benutzerdefinierte Kategorie unter einem bestehenden Elternteil. Verändert Daten, deshalb ist banking:write statt banking:read nötig.
Erforderlicher Scope
banking:writeslug | URL-sicherer Bezeichner — Kleinbuchstaben, Ziffern und Bindestriche, 2 bis 50 Zeichen. |
|---|---|
parentCategoryKey | Der fcat_-Schlüssel der Kategorie, unter der diese eingehängt wird. |
name | Anzeigename. |
descriptionoptional | Optionale Beschreibung. |
iconNameoptional | Optionaler Icon-Name. |
spendingTypeoptional | Optionale Ausgabenklassifizierung. |
displayOrderoptional | Optionale Sortierposition unter den Geschwisterkategorien. |
assignmentEligibilityoptional | Optionale Regel dafür, welchen Transaktionen diese Kategorie zugewiesen werden darf. |
sourceSystemKeysoptional | Optionale Liste bestehender Kategorie-Schlüssel, deren Transaktionen künftig hierher geleitet werden sollen. |
applyRetroactivelyoptional | Bei true werden auch vergangene Transaktionen gegen das neue Routing neu bewertet. Standardmäßig false. |
Antwort · 201
{
"categoryKey": "fcat_side_hustle_9f2a",
"overlayProjectionKey": "fcov_9f2a1c",
"action": "created",
"isQuotaExceeded": false,
"createdMappingRuleKeys": [ … ],
…
}
Die Antwort trägt außerdem retroactiveAffectedCount, mergeSourcesHiddenCount, mergeSourcesTotalCount und meterGate — Felder, die dieser Aufruf mit Kategorien-Zusammenführungen und quotenbegrenzten Neuanlagen teilt und die hier nicht gezeigt werden.