メインコンテンツへスキップ

Era API

Era APIのエンドポイント、認証、ページング、制限を、コピーして使えるリクエストとともに解説します。

最終更新:2026年10月1日

まだベータ版です

これらのエンドポイントは今日時点で動作しますが、APIはまだ発展途上であり、一部の詳細は変わる可能性があります。このページが最後に更新された日時は、ページ上部の最終更新日で確認できます。

クイックスタート

始める前に、Eraのアカウントと、少なくとも1つの金融機関の接続が必要です。接続がないと、これらのエンドポイントは返すものがありません。

  1. 1

    Eraにサインインし、まだなら金融機関を接続します。

  2. 2

    ダッシュボードのAPIキーを開いてキーを作成します。ほとんどのスコープには最初からチェックが入っていますが、お金を動かす、売買注文を出す、請求内容を変更する、ドキュメントを削除する、キーをさらに作成する、といったことができるスコープには入っていません。要らないものは外してください。読み取りにはbanking:read、何かを変更するにはbanking:writeが必要です。有効期限も選びます。無期限という選択肢はありません。

  3. 3

    キーをコピーして、シークレットマネージャーなど安全な場所に保管してください。表示は一度だけなので、紛失した場合は新しいキーを作成してください。

  4. 4

    リクエストのヘッダーに載せて送ります。

cURL
curl "https://forge.era.app/api/banking/transactions?page=1&pageSize=20" \
  -H "X-API-Key: fmk_your_key_here"
レスポンス · 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
}

自分でクライアントを書くなら、https://forge.era.app/api/openapi/public.json にあるOpenAPIドキュメントから生成してください。このページのすべてのエンドポイントについて、フィールド、ステータス、ルールのフィルターとアクションの種類を一つ残らず記述しています。API自身が配信しているので、内容が古くなることはありません。

エンドポイント

エンドポイントは十七個です。読み取りが八個、書き込みが九個です。

認証

キーは次のいずれかの方法で送ってください:

認証方法
ヘッダー
X-API-Key: fmk_your_key_here
ベアラートークン
Authorization: Bearer fmk_your_key_here

すべてのリクエストはTLSで暗号化されます。

キーには有効期限があり、作るときにどれくらいで切れるかを選びます。最長は無料プランで90日、有料プランで365日です。無期限という選択肢はないので、これを使って作るものには、期限が来る前にキーを入れ替える段取りが要ります。

レスポンスヘッダー

X-RateLimit-*ヘッダーは1日の予算を伝えるもので、1日の予算を公開しているプランでのみ表示されます。当面、それは無料プランだけです。無料プランでも、ヘッダーはないこともあるものとして扱ってください。ヘッダーのないレスポンスは件数が不明という意味で、問題が起きたわけではありません。429にはすべてRetry-Afterが付きます。

レスポンスヘッダー
X-RateLimit-Limit
プランの1日の予算です。1日の予算を公開しているプランでのみ送られ、1日の予算以外の上限による429には付きません。
X-RateLimit-Remaining
1日の予算の残りです。ゼロを下回ることはありません。1日の予算を公開しているプランでのみ送られ、1日の予算以外の上限による429には付きません。
X-RateLimit-Reset
1日の予算で次のリクエストが1件空く時刻を、Unix時間の秒で示します。予算全体が戻る時刻ではありません: 予算は順に戻るため、リクエストは1件ずつ戻ってきます。1日の予算を公開しているプランでのみ送られ、1日の予算以外の上限による429には付きません。1分あたりのバースト上限に専用のヘッダーはありません。参照: 制限
Retry-After429のみ
429にはすべてRetry-Afterが付きます。その秒数だけ待ってから再試行してください。X-RateLimit-*ヘッダーも付いた429は、無料プランの1日の予算による拒否です。付いていない429は、1分あたりのバースト上限など、それ以外の上限による拒否です。Retry-Afterは1秒から24時間までの値になります。参照: 制限

エラー

このAPIが返すエラーのステータスコードは次のとおりです:

  • 400

    不正な入力: パラメータの誤り、空または100件を超える一括更新、同じ呼び出しで同じフィールドを設定と解除の両方を行う書き込み、あるいは整合性のないルール。ルールの削除・オン・オフでは、受け付けないクエリキーも拒否され、400がそのキー名を示します。

  • 401

    キーがない、または解析できないキー。X-API-Keyヘッダーかベアラートークンとして送ってください。

  • 402

    プランのクォータに引っかかっています。現時点では、カテゴリかパターンルールの作成にのみ当てはまります。待っても解消しませんが、上位プランなら解消します。呼び出しが速すぎる場合は、代わりに429になります。

  • 403

    キーがこの呼び出しに必要なスコープを持っていない — または、二つの取引書き込みのいずれかで、idが他人のものか、そもそも存在しない場合。APIはこの二つを区別しません。 Eraのライブラリのルールを削除しようとしたり、名前、説明、優先度、日付、applicationScopeを変更しようとしたりすると403になります。フィルター、アクション、グループを変更した場合は、代わりに400になります。

  • 404

    存在しないものです。残高エンドポイントは、どの口座も指していない accountGroupKey や、そもそもキーの形をしていない値に対して、ボディなしの404を返します。ルールのエンドポイントは、自分のものではないルールキーに対して404を返します。取引が404を返すことはありません — 403を参照してください。

  • 409

    書き込み中に別の何かがその行を変更しました。ルールの場合は、versionが現在のものではないということです。もう一度読み込んで、もう一度書き込んでください。ルールでは、409はそのアクションがルール同士を堂々巡りで発動させてしまうことを意味する場合もあります。その場合はアクションを変えてください。

  • 429

    リクエストが多すぎます。無料プランで1日の予算を使い切ったか、1分あたりのバースト上限などの別の上限に達しました。待つ時間はRetry-Afterでわかり(1秒から24時間まで)、402とは違い、待てば次のリクエストが空きます。公開している数値と、429が伝えることは、制限の節を参照してください。

エラーの形

ほとんどのエラーは同じ形で返ります: statusCode、message、そして何が問題だったかを示すerrorsオブジェクトです。すべてではありません。401と、残高エンドポイントの404は本文なしで返るので、本文より先にステータスを読んでください。

例
{
  "statusCode": 403,
  "message": "One or more errors occurred!",
  "errors": {
    "generalErrors": ["Transaction does not belong to the authenticated user"]
  }
}

よくあるエラー

  • 同じ書き込みでフィールドを設定と解除の両方を行う — 400。

  • 一括更新で100件を超えるid — 400、何も変更されません。1件未満も同様です。

  • 自分のものではない、あるいは存在しない取引 — 403、404にはなりません。つまりレスポンスは、そのidが存在するかどうかを決して教えず、ただ「あなたのものではない」とだけ伝えます。

  • 他の何かが先にその行を変更した — 409。

制限

ドキュメント化されたエンドポイントのうち二つは、1回の呼び出しでリクエストできる量に上限があります。それ以外にはありません。

1回あたりの上限がないからといって、無制限というわけではありません。キーには引き続き有効期限があり、書き込みには引き続きフィールド長の制限があり、カテゴリやパターンルールの作成はプランのクォータに達することがあり、プランによっては古い履歴が引き続き隠され、どの呼び出しもプランのレート制限に数えられます(下記参照)。

  • アカウント、残高、サマリー、カテゴリとタグの一覧、カテゴリの作成、タグの作成、単一トランザクションの書き込み、そしてすべてのルールのエンドポイントには、呼び出しごとの量的な上限がありません。指定したセット全体、または指定した1行がそのまま返されます。ただしルールのプレビューは例外で、一致を数えますが、返すのはそのキー最大50件とサンプル最大10件だけです。

  • pageSizeは拒否ではなく100に切り詰められます。それ以上を要求しても、200とともに100件が返ってきます — 送った値を信じるのではなく、レスポンスのpagination.pageSizeを読んでください。

  • 取引の一括書き込みは100件のidに制限されており、pageSizeと違って切り詰めではなく拒否されます: 101件送ると400が返り、何も変更されません。

  • キーは作成時に選んだスケジュールで期限切れになります — 無料プランで最大90日、有料プランで365日です。無期限のオプションはありません。

  • プランによっては、古い取引を隠す履歴ウィンドウの下限が適用されることがあります。取引のレスポンスには、下限が適用されたかどうかとその位置を示すhistoryWindowフィールドが含まれます。

レート制限

Eraが公開しているレート制限は2つです。すべてのプランにバースト上限があります。直近の1分間ごとのリクエスト数の上限です。無料プランには、さらに1日の予算があります。直近の24時間ごとのリクエスト数の上限です。リクエストは、送ってから1分後にバースト上限の計算から外れ、1日後に1日の予算の計算から外れます。当面、有料プランには公開された1日の予算がありません。このどちらか、またはAPIが適用するほかの上限を超えると、呼び出しには429が返ります。

上限はキーではなく、アカウントに属します。作成したすべてのRESTキーが同じバースト上限を使い、無料プランでは同じ1日の予算も使うので、キーを増やしても呼び出しは増えません。MCPツールの呼び出しは別に数えられるため、REST呼び出しとMCP呼び出しが互いの上限を消費することはありません。

プラン別のレート制限
プラン1日の予算バースト上限
Basic1日あたり100件1分あたり10件
Organizeなし1分あたり30件
Automateなし1分あたり60件
Optimizeなし1分あたり60件
Operateなし1分あたり120件

当面、有料プランには公開された1日の予算がありません。

有料プランには、フェアユースも適用されます。APIは、ご自身の金融データを使うスクリプト、ダッシュボード、連携のためのもので、1人で使うのにふさわしい量を想定しています。

どのプランでも、バースト上限を伝えるヘッダーはないので、表を目安にペースを調整してください。無料プランでは、バーストが429で返る直前でも、X-RateLimit-Remainingがゼロを大きく上回っていることがあります。

429が伝えること

どの上限で拒否されたかがわかります。X-RateLimit-*ヘッダーが付いた429は無料プランの1日の予算、付いていない429はバースト上限など、それ以外の上限によるものです。ボディはproblem-details形式で、detailフィールドには次のリクエストが空く時刻が書かれています。1日の予算かバースト上限で拒否された場合は、その上限の種類、その上限で許される量、そして上限を引き上げるか撤廃するプラン(すでに最上位ならその旨)も書かれています。人が読むための文なので、解析せずにヘッダーを読んでください。

429レスポンス(1日の予算)
{
  "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."
}

429には必ずRetry-Afterも付きます。秒数を表す整数で、1秒から24時間までの値です。バースト上限の待ち時間は最大1分ですが、無料プランの1日の予算では24時間いっぱい待つこともあります。拒否された呼び出しはどの上限にも数えられませんが、早めに再試行しないでください。どの429でも、Retry-Afterが過ぎるまで待ってください。1日の予算とバースト上限では、早すぎる再試行は再び拒否され、待ち時間が終わると空くのは1リクエスト分で、上限全体ではありません。送ってから、返ってきた内容を確認してください。拒否されれば次のRetry-After、無料プランで処理されればヘッダーが返ります。

レート制限は、見失ったキーを守ってはくれません。漏えいしたキーは、アカウント内のほかのすべてのキーと同じ上限を使い、そのスコープで許されることは何でもできます。キーを失効させても、すでに行われた呼び出しは戻りません。キーに不安があれば、失効させてください。詳しくは下のセキュリティとキーの扱いを参照してください。

共通の決まり

レスポンスのフィールドはcamelCaseです。クエリパラメータの名前は大文字と小文字を区別しませんが、それ以外はこのページの表記どおりに書く必要があります。たとえばpageSizeとPageSizeはどちらも通ります。公開している仕様書では、ほとんどがPascalCaseで書かれています。ほとんどのエンドポイントは受け付けないクエリキーを無視するので、つづりを間違えたフィルターは単に効きません。返ってきた内容を確認してください。例外はルールの削除・オン・オフで、それ以外のキーはそのキー名を示した400で拒否されます。revert_retroactivelyはアンダースコア付きで送ってください(revertRetroactivelyは拒否されます)。また、送るのは削除とオフのときだけです。オンで受け付けるのはversionだけです。

暦の上の一日を指すフィールドはYYYY-MM-DDです。ある瞬間を指すフィールドは、オフセット付きのISO 8601です。

ページの大きさは、はねつけられるのではなく丸められます。pageSizeに500を指定しても、返るのは100件と200であって、エラーではありません。送った値を信じるのではなく、pagination.pageSizeを読み返してください。

レスポンスには、このページに載っていないフィールドが入っていることがあります。知らないものはエラーにせず読み飛ばしてください。そうしておけば、APIが広がっても手元のクライアントは動き続けます。

RESTは素のHTTPなので、呼び出すのにSDKは要りません。HTTPクライアントのある言語ならどれでも大丈夫です。インストールするものはありません。

バージョンと変更

APIはベータ版なので、エンドポイントやフィールド、呼び出しの動作など、ここに書かれている内容は変わることがあります。

パスにバージョン番号はなく、バージョン用のヘッダーもありません。各エンドポイントで動いているバージョンはひとつで、それがここに書かれているものです。

変更履歴

Era Developer Platform(Era APIを含む)の変更点を、新しい順に。メールやフィードでのお知らせはないので、APIを使った作業を計画するときは変更履歴を確認してください。

セキュリティとキーの扱い

エージェントを承認するとキーが一つ作られます

OAuthでエージェントを承認すると、EraはそのためのAPIキーを作ります。自分で作ったキーと同じダッシュボードの一覧に、クライアント自身の名前からEraが組み立てた名前で並びます。

名前の付き方

Auto -- Claude

その画面で承認したスコープをそのまま持ち、それ以外は持ちません。ダッシュボードから失効させると、再度承認するまでエージェントは新しいアクセス権を得られません。すでに持っているトークンは有効期限まで使え、その期限は最長1時間です。

書き込みはアクティビティログに残り、読み取りは残りません

キーの作成と失効はどちらもアクティビティログに残り、エージェントがMCPで行うツール呼び出しもすべて残ります。RESTの書き込みも残ります——タグを作成した、取引を編集したといった変更として記録されます。RESTの読み取りはエントリを一切作りません。これらのエントリはどのプランでも記録されますが、ログ全体を読むにはOrganize以上が必要です。それ未満では直近のエントリだけが見えます。書き込みのエントリに記録されるのはアカウントで、変更を行ったキーではありません。

キーに不安を感じたら、失効させてください。自分で作成したキーは、次のリクエストからRESTとMCPの両方で使えなくなります。エージェントのキーはただちに新しいアクセス権を得られなくなり、すでに持っているトークンも1時間以内に失効します。作り直しにかかるのは1分です。

キーに頼る前に知っておきたいこと。
スコープは粗い
banking:readはこのページの読み取りよりずっと広い範囲を読みます。同じスコープがアカウントの残りの読み取り、つまり残高、保有資産、接続、支出までカバーします。スコープはこれひとつ、これより狭い選択肢はありません。 書き込み系のスコープも、読み取り系と同じく選択肢に入っています——キーはあなたのEraアカウントとして動くので、パスワードと同じように扱ってください。口座の一部ではなく、Eraアカウント全体として動きます。
banking:writeが変えるのはEraで、銀行ではありません
banking:writeが変えるのはEraが保持している内容だけで、銀行にあるものは何も変えません。お金を動かすことも、支払いをすることもできません。banking:readと同じく、banking:writeも広い範囲をカバーするひとつのスコープです。対象はEraで自分でできる変更で、たとえば取引のカテゴリ、加盟店名、メモ、レビューステータス、カテゴリ・タグ・自動化ルール、Eraがアカウントに表示する名前とどのアカウントを表示するか、そして手動アカウントとその残高・取引です。新しい接続を始めることはできますが、銀行へのサインインはキー経由ではなく、提供事業者の画面であなた自身が行います。新しい同期(読み取るだけです)を依頼することや、金融機関の接続を解除することもできます。接続を解除するとEraとのつながりが切れるだけで、銀行の口座は開いたまま、何も変わりません。
スコープは更新されない
キーのスコープは作成時に決まり、あとから変わることはありません。これは、スコープに含まれてはいてもまだ使えないものについて効いてきます。今日social:writeを渡せば、共有ビューが使えるようになった日にもそのキーはそれを持ったままです。今使うものだけを渡し、いつか使うかもしれないものは渡さないでください。
承認は不要
キーの作成に審査も順番待ちもなく、Eraの誰かが申請を承認することもありません。作成した瞬間にアクティビティログへ記録されるので、身に覚えのないキーはすぐに気づけます。
銀行のログイン情報には届かない
キーは銀行のログイン情報に届きません。Eraがそれを持っていないからです。入力するのはデータ提供事業者が用意した接続画面で、Eraの画面ではありません。Eraが後に保持するのは接続ごとのアクセストークンだけで、AES-256で暗号化されて保存され、金融機関の接続を解除すれば捨てられます。
Eraが保存するのはキーのハッシュだけ
キーは256ビットのランダムなデータです。EraはそれをSHA-256でハッシュ化し、ハッシュだけを保存します。紛失したら失効させて、新しいキーを作成してください。

主なリソース

口座

GET/banking/accounts
必要なスコープbanking:read

接続済みの金融機関をまたいで、見えている口座をすべて返します。外してある口座の件数も一緒に付きます。その件数がexcludedAccountCountで、プランの口座数上限で外れているtierExcludedAccountCountと、自分で隠したuserExcludedAccountCountに分かれています。accountLimitは、すべての接続を合わせてプランが一度に表示できる口座数です。accountLimitLiftは隠していない口座がすべて収まる一番安いプランの名前で、プランで外れている口座がないときはnullです。どの口座にも、残高のエンドポイントがパスで受け取る値であるaccountGroupKeyと、その口座が属するconnectionIdが入っているので、まずはこの呼び出しから始めてください。connectionIdで一つの接続に絞り込め(件数は一緒に絞り込まれますが、accountLimitとaccountLimitLiftは変わりません)、includeExcludedでプランで外れている口座と自分が隠した口座も含められます。

クエリパラメータ
connectionId任意
一つの接続の口座だけに絞り込みます。
includeExcluded任意
プランで外れている口座や自分で隠した口座も含め、残高は伏せて返します。どちらなのかは各行のvisibilityでわかります。tierExcludedかuserExcludedで、それ以外はvisibleです。残高のエンドポイントはこれらを別の書き方で返すので、両方に同じパーサーを使わないでください。これがtrueでもexcludedAccountCountは返りますが、その口座はすでにリストに入っているので、両方を足さないでください。デフォルトはfalseです。
レスポンス · 200
{
  "accounts": [
    {
      "accountGroupKey": "uagr_7f3c9a21",
      "connectionId": "ucon_4b19e02c",
      "name": "Everyday Checking",
      "currentBalance": 4820.16,
      "supportsTransactions": true,
      …
    }
  ],
  "excludedAccountCount": 1
}

自分が隠した口座や、プランの対象外になっている口座では、残高のフィールドはゼロではなくnullで返ります。nullは「空」ではなく「伏せてある」という意味です。supportsTransactionsのnullも同じ考え方で、Eraには言えないという意味であって、答えが「いいえ」だという意味では決してありません。プラン関連のフィールドも同じです。その呼び出しでEraがプランを読み取れなかった場合、tierExcludedAccountCount、userExcludedAccountCount、accountLimit、accountLimitLiftはすべてnullで返ります。口座数に上限のないプランではaccountLimitもnullになり、これ以上余裕のあるプランがない場合や、プランで外れている口座がない場合はaccountLimitLiftがnullになります。

口座の残高

GET/banking/accounts/{accountId}/balance
必要なスコープbanking:read

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.

レスポンス · 200
{
  "accountGroupKey": "uagr_7f3c9a21",
  "currentBalance": 4820.16,
  "availableBalance": 4712.03,
  "creditLimit": null,
  "currencyCode": "USD",
  "availableCredit": null,
  "asOf": "2026-08-11T09:32:00Z",
  "visibility": null
}

隠した口座も、接続が切れた口座も、返ってくるのは200のままで、残高のフィールドがnullになります。404は、その口座が本当に存在しないか、キーがキーの形をしていなかったことを意味します。ここではvisibilityのフィールドに注意してください。口座が見えているときはnull、プランの口座数上限で外れているときはtier_excluded、自分で隠したときはuser_excluded、接続が切れたときはconnection_severedが入ります。tier_excludedのときは、accountLimitがプランの上限で、accountLimitLiftがこの口座を含め隠していない口座がすべて収まる一番安いプランの名前です。それ以外の状態ではaccountLimitLiftはnullで、connection_severedのときはaccountLimitもnullです。

口座のまとめ

GET/banking/accounts/summary
必要なスコープbanking:read

見えている口座の合計です。標準ではライブ口座が対象で、totalAssets、totalLiabilities、そして前者から後者を引いたnetWorthHintが入ります。simulationModesを渡すと、どのモードを数えるかを選べます。口座の一覧と合計は、指定したモードだけを対象にします。どのモードを対象にしたかはincludedSimulationModesが毎回のレスポンスで示します。simulationExcludedAccountCountは、モードのせいで除外された、見える口座の数です。totalHiddenCountは別の数で、プランやご自身の表示設定で非表示になっている口座をどのモードでも数え、simulationModesで除外された口座は含みません。

クエリパラメータ
simulationModes任意
合計する口座の種類です。liveは実際のお金、paperは証券会社の練習用口座、scenarioは仮想の口座です。複数指定するにはパラメータを繰り返します(例:simulationModes=live&simulationModes=paper)。省略するとライブ口座だけが対象です。空の値や未知の値は、使える値を示す400で拒否されます。
レスポンス · 200
{
  "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が数えるのはこのレスポンスに入っている口座だけで、外れているものは2つの数でわかります。simulationExcludedAccountCountは、指定したモード以外の口座の数です。totalHiddenCountは、どのモードでも非表示になっている口座の数です。内訳は2つで、tierExcludedAccountCountはプランの口座数上限で外れている口座、userExcludedAccountCountは自分で隠した口座です。その呼び出しでEraがプランを読み取れなかった場合、どちらもnullになります。accountLimitLiftは前者を戻せる一番安いプランの名前で、前者がないときはnullです。netWorthHintは確定した純資産ではなく、出発点の数字として扱ってください。

取引

GET/banking/transactions
必要なスコープbanking:read

取引を1ページずつ、ページ数の情報と一緒に包んで返します。pageとpageSize(上限は100)を受け取り、口座、期間、適用済みルール、付与済みタグでの絞り込みも指定できます。

クエリパラメータ
accountId任意
一つの口座の取引に絞り込みます。その口座のaccountGroupKeyで指定します。
fromDate任意
この日付以降の取引だけを返します。
toDate任意
この日付以前の取引だけを返します。
page任意
ページ番号。1から始まります。デフォルトは1です。
pageSize任意
1ページあたりの件数。デフォルトは50で、100までに制限されます。
sortBy任意
並べ替えるフィールド:transactionDate、amount、description、category、merchantNameのいずれか。
sortDirection任意
ascまたはdesc。デフォルトは降順です。
categoryKeys任意
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.
search任意
加盟店名、説明、カテゴリ、口座名、金額を対象にした全文検索です。
ruleIds任意
自動化ルールが適用された取引だけに絞り込みます。ルールのキーで指定します。
tagKeys任意
指定したタグのいずれかが付いた取引だけに絞り込みます。
reviewStatuses任意
needs_review、reviewed、flaggedのいずれかです。複数指定でき、レビュー状態がそのいずれかに一致する取引が返されます。
includeChildren任意
With a category filter set, also include transactions in the subcategories of every key you passed. Defaults to false.
includePending任意
過去7日間の保留中の取引も返します。isPending が付きます。デフォルトはfalseです。保留中の行は読み取り専用です。
レスポンス · 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
}

プランによっては履歴ウィンドウの境目が適用され、それより古い取引は隠れます。レスポンスにhistoryWindowのフィールドが並んでいるのはそのためです。historyWindowAppliedは境目が実際に何かを隠したことを示し、historyWindowFloorDateはその境目の位置、historyWindowHiddenCountは後ろに何件あるか、historyWindowEarliestDateは履歴が実際にどこまで遡れるかを示します。これがないと、件数が少ない結果は「それ以上古い取引がない口座」と見分けがつきません。このうち二つは書くコードを左右します。historyWindowHiddenCountは境目が適用されていてもnullになることがあるので、nullはゼロではなく「不明」として読んでください。historyWindowDegradedがtrueのときは、その読み取りでEraがプランを確認できていないため、境目の日付は事実ではなく推測です。プランを確認できた有料の読み取りでは境目は適用されず、historyWindowAppliedはfalseで返ります。プランの口座数上限でも取引は外れます。tierExcludedAccountCountはこの読み取りから上限で外れている口座の数、userExcludedAccountCountは自分で隠した口座の数で、口座で絞り込んだ場合はどちらもその口座だけを数えます。その呼び出しでEraがプランを読み取れなかった場合は、どちらもnullです。

長い履歴をページ送りで読むと、リクエストを消費します。プランは呼び出せる速さを制限し、無料プランでは1日に使える呼び出し数も制限します。有料プランはフェアユースの範囲でご利用いただけます。プランごとの数値、レート制限ヘッダー、そして429が伝えることは、制限の節にまとめています。

取引を一件変更する

取引のうち、自分で上書きできるのは四つです。カテゴリ、加盟店名、自分で付けるメモ、そしてレビューステータス。変更するものだけを送ってください——省略した項目はそのままです。パスのidは、その取引のutgr_キーです。banking:readではなくbanking:writeが必要ですが、変わるのはEra側にある取引のコピーだけで、銀行側の取引はそのままです。

PUT/banking/transactions/{id}
必要なスコープbanking:write
リクエストボディ
categoryKey任意
割り当てるカテゴリのfcat_キー。省略すると、取引は今のカテゴリのままです。
merchantName任意
自分で付ける加盟店名。最大1000文字。省略すると、今の名前のままです。
description任意
この取引に自分で付けるメモ。最大5000文字。省略すると、今のメモのままです。
clearCategory任意
カテゴリの上書きを外し、Era自身の分類に戻します。デフォルトはfalseです。
clearMerchantName任意
加盟店名の上書きを外し、銀行から届いた名前に戻します。デフォルトはfalseです。
clearDescription任意
メモの上書きを外し、銀行から届いた説明に戻します。デフォルトはfalseです。
reviewStatus任意
needs_review、reviewed、flaggedのいずれかを付けます。
clearReviewStatus任意
レビューステータスの上書きを外します。デフォルトはfalseです。
レスポンス · 200
{
  "transaction": { … }
}

更新された取引がまるごと返ります。形は上の一覧が返すものと同じです——ここでは繰り返して載せていません、大きく、APIがベータ版のあいだは変わり続けるためです。同じ呼び出しの中でフィールドを設定しつつ同時にクリアすると400が返ります。自分のものではない取引、あるいはそもそも存在しない取引は403が返ります——このAPIは両者を区別しません。書き込んでいる間に別の何かが同じ行を変更していた場合は409が返ります。読み直してから、もう一度送ってください。

一度に100件まで変更する

同じ四つの上書きを、一度の呼び出しで複数の取引のリストに適用します。リストに含めたすべてのidが同じ変更を受け取ります——取引ごとに内容を変えることはできません。banking:readではなくbanking:writeが必要ですが、変わるのはEra側にあるそれらの取引のコピーだけで、銀行側の取引はそのままです。

PUT/banking/transactions/bulk
必要なスコープbanking:write
リクエストボディ
transactionIds
変更する取引のutgr_キー。最低1件、最大100件です。100件を超えると、上のpageSizeとは違って丸められるのではなく拒否されます——400が返り、何も変更されません。
categoryKey任意
割り当てるカテゴリのfcat_キー。省略すると、取引は今のカテゴリのままです。
merchantName任意
自分で付ける加盟店名。最大1000文字。省略すると、今の名前のままです。
description任意
この取引に自分で付けるメモ。最大5000文字。省略すると、今のメモのままです。
clearCategory任意
カテゴリの上書きを外し、Era自身の分類に戻します。デフォルトはfalseです。
clearMerchantName任意
加盟店名の上書きを外し、銀行から届いた名前に戻します。デフォルトはfalseです。
clearDescription任意
メモの上書きを外し、銀行から届いた説明に戻します。デフォルトはfalseです。
reviewStatus任意
needs_review、reviewed、flaggedのいずれかを付けます。
clearReviewStatus任意
レビューステータスの上書きを外します。デフォルトはfalseです。
レスポンス · 200
{
  "transactions": [ … ]
}

更新された取引が返ります。形は上の一覧が返すものと同じです。同じ呼び出しの中でフィールドを設定しつつ同時にクリアすると400が返り、空のリストを送った場合も400です。自分のものではない取引、あるいはそもそも存在しない取引がリストに一件でも含まれていると、呼び出し全体が403になります——何も変更されません。書き込んでいる間に別の何かがそれらの行のどれかを変更していた場合は409が返ります。読み直してから、もう一度送ってください。

カテゴリ

GET/banking/categories
必要なスコープbanking:read

カテゴリ体系のすべて。カテゴリのまとまりごとに、その下位カテゴリが入れ子で入ります。この体系は共通で、口座ごとではありません。

レスポンス · 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
}

カテゴリを追加する

既存の親カテゴリの下に作る、ユーザー定義のカテゴリです。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのカテゴリだけで、銀行側では何も変わりません。

POST
必要なスコープbanking:write
リクエストボディ
slug
URLで使える識別子——小文字、数字、ハイフンのみ、2〜50文字。
parentCategoryKey
このカテゴリを入れ子にする親カテゴリのfcat_キー。
name
表示名。
description任意
任意の説明。
iconName任意
任意のアイコン名。
spendingType任意
任意の支出分類。
displayOrder任意
兄弟カテゴリの中での任意の並び順。
assignmentEligibility任意
このカテゴリをどの取引に割り当てられるかを決める任意のルール。
sourceSystemKeys任意
今後ここへ振り分ける、既存カテゴリキーの任意のリスト。
applyRetroactively任意
trueにすると、過去の取引も新しい振り分けで再評価します。デフォルトはfalseです。
レスポンス · 201
{
  "categoryKey": "fcat_side_hustle_9f2a",
  "overlayProjectionKey": "fcov_9f2a1c",
  "action": "created",
  "isQuotaExceeded": false,
  "createdMappingRuleKeys": [ … ],
  …
}

レスポンスにはretroactiveAffectedCount、mergeSourcesHiddenCount、mergeSourcesTotalCountも含まれます。これらはこのページでは扱いません。さらにisQuotaExceeded、quotaExceededMessage、meterGateも含まれますが、作成できたカテゴリではそれぞれ常にfalse、null、nullです。プランの上限で作成が断られた場合は代わりに402が返り、これらのフィールドはどれも入りません。本文はstatusCode、message、errors.generalErrorsで、errors.generalErrorsのただ一つの項目が、どの上限に達したかを伝えます。

タグ

GET/banking/tags
必要なスコープbanking:read

アカウントのタグをすべて、ひとつのリストで返します。ページ分割はありません。1回のレスポンスですべて返ります。

クエリパラメータ
tagType任意
タグの発生元で絞り込みます:user、system、autoのいずれか。
includeDeleted任意
削除済みのタグも含めます。デフォルトはfalseです。
レスポンス · 200
{
  "tags": [
    {
      "tagKey": "utag_9c2f01ab",
      "name": "business-expense",
      "displayName": "Business expense",
      "tagType": "user",
      "color": "#6DC6BA",
      "transactionCount": 42
    }
  ]
}

タグを作成する

新しいタグです。名前は小文字に正規化されます。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのタグだけで、銀行側では何も変わりません。システムタグはAPIでは作成できません。userタグとautoタグは作成できます。

POST
必要なスコープbanking:write
リクエストボディ
name
タグの正規名。
displayName任意
任意の表示名。デフォルトは正規名です。
tagType任意
user or auto. Defaults to user. system is refused — it is reserved for tags Era creates itself.
color任意
表示用の任意の16進カラー。
icon任意
任意のアイコン名。
レスポンス · 201
{
  "tag": {
    "tagKey": "utag_9c2f01ab",
    "name": "business-expense",
    "displayName": "Business expense",
    "tagType": "user",
    "version": 1,
    "createdAt": "2026-08-26T09:15:00Z"
  }
}

ルール

GET/banking/rules
必要なスコープbanking:read

アカウントのすべての自動化ルールです。自分で作ったものも、Eraがルールライブラリから設定したものも含み、それぞれに条件(filters)、実行する内容(actions)、オンかどうか、そしてバージョンが付きます。ページ分割はありません。1回のレスポンスですべて返ります。オフのルールは、指定しない限り含まれません。

クエリパラメータ
includeInactive任意
オフになっているルールも返します。デフォルトはfalseです。
レスポンス · 200
{
  "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とactionsは、型付きオブジェクトのリストです。それぞれtypeフィールドで種類を示します——フィルターならmerchant_matchやcategory、アクションならset_categoryやadd_tagなど。すべての種類と、それぞれが受け取るフィールドは、クイックスタートからリンクしているOpenAPIドキュメントに載っています。

ルールを作成する

新しい自動化ルールです。取引を選び出す条件と、条件に一致した取引それぞれに起きることで構成されます。作成後は新しい取引すべてに適用され、指定すればすでにある取引にも適用されます。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのルールと取引だけで、銀行側では何も変わりません。

POST
必要なスコープbanking:write
リクエストボディ
ruleName
ルールの名前です。
description任意
ルールの用途についての任意のメモです。
priority任意
ほかのルールの中でこのルールが実行される位置です。高いものが先に実行され、二つのルールが一つの取引に同じ項目を設定しようとした場合は、高いほうが優先されます。デフォルトは0です。
filters
条件です。型付きフィルターオブジェクトのリストで、それぞれtypeフィールドで種類を示します。取引はすべての条件を満たす必要があります。別の組み合わせにしたい場合は、and、or、notのフィルターを入れ子にしてください。最低一つ必要です。口座の種類を指定したaccount_typeフィルターはパターンルールでのみ使えます。取引ルールでは400で拒否されます。
actions
ルールに一致した取引それぞれに何をするかです。型付きアクションオブジェクトのリストで、カテゴリの設定、タグの追加や削除、加盟店名の変更、説明の書き換え、レビューステータスの設定、非表示、振替としてのマークができます。最低一つ必要で、タグのアクションを除き、各種類は一つまでです。各タグはあらかじめ存在している必要があり、一度しか指定できません。
isActive任意
ルールをオンの状態で始めるかどうかです。デフォルトはtrueです。
applyRetroactively任意
新しい取引だけでなく、すでにある取引にもルールを適用します。ルールがオンの状態で始まる場合にのみ有効です。デフォルトはfalseです。
appliesFrom任意
この日付以降の取引だけが対象です。
appliesTo任意
この日付以前の取引だけが対象です。
applicationScope任意
ルールをいつ実行するかです。新しい取引だけならprospective、既存の取引に対して実行するときはretroactive、両方ならbothです。デフォルトはbothです。
ruleScope任意
デフォルトのtransactionは、取引を一件ずつ判定します。patternは、定期的な請求や一組の振替のように、複数の取引にまたがるパターンを見つけます。パターンはpatternSpecで記述します。
triggerMode任意
パターンルールで、いつパターンを確認するかです。onEachTransaction、onBatchComplete、onSchedule、onDemandのいずれかで、デフォルトはonEachTransactionです。
patternSpec任意
パターンルールで探すパターンで、型付きオブジェクトとして指定します。ruleScopeがpatternのときは必須です。
windowDays任意
パターンルールで、パターンの残りを何日前までさかのぼって探すかです(1〜365日)。ruleScopeがpatternのときは必須です。
windowLookaheadDays任意
パターンルールで、パターンの残りを何日先まで探すかです。
windowExcludeTriggerAccount任意
パターンルールで、確認のきっかけになった取引の口座を検索対象から外します。デフォルトはfalseです。
group任意
ルールを分類するグループです。spendingHabits、problemsAndAnomalies、incomeAndTransfers、subscriptionsAndRecurring、taxAndRecordKeepingのいずれかです。省略するとどのグループにも入りません。categoryMappingはEra自身が作るルール用に予約されており、400で拒否されます。
レスポンス · 201
{
  "rule": { … },
  "retroactiveStatus": "completed",
  "affectedTransactionCount": 18
}

retroactiveStatusは、既存の取引にルールを適用する、またはルールが行ったことを取り消すよう呼び出しで求めた場合を除き、nullです。completedはその処理がレスポンスの前に終わったこと、in_progressはまだ実行中でaffectedTransactionCountが確定していないこと、queue_fullはキューが満杯で処理が始まらなかったこと(ルール自体の変更は保存されています)、partial_successは一部しか通らなかったこと(一部の変更が保存されなかった、または処理の一部しかキューに入らなかった)を表します。

ルールをプレビューする

ルールの条件を最近の取引に当てはめ、何に一致するかを、何も保存せずに報告します。確認した件数のうち一致した件数、一致した取引のキー(最大50件)、そしてサンプル(最大10件)を返します。取引ルールは直近90日間の取引を最大5,000件まで確認し、そのサンプルには加盟店名・金額・日付が入ります。パターンルールのサンプルにはdetectionReason(パターンが検出された理由。空の場合もあります)が入り、加盟店名・金額・日付は入りません。何も書き込まないので、banking:readで足ります。

POST/banking/rules/preview
必要なスコープbanking:read
リクエストボディ
filters
条件です。型付きフィルターオブジェクトのリストで、それぞれtypeフィールドで種類を示します。取引はすべての条件を満たす必要があります。別の組み合わせにしたい場合は、and、or、notのフィルターを入れ子にしてください。最低一つ必要です。口座の種類を指定したaccount_typeフィルターはパターンルールでのみ使えます。取引ルールでは400で拒否されます。
ruleScope任意
デフォルトのtransactionは、取引を一件ずつ判定します。patternは、定期的な請求や一組の振替のように、複数の取引にまたがるパターンを見つけます。パターンはpatternSpecで記述します。
patternSpec任意
パターンルールで探すパターンで、型付きオブジェクトとして指定します。ruleScopeがpatternのときは必須です。
windowDays任意
パターンルールで、パターンの残りを何日前までさかのぼって探すかです(1〜365日)。ruleScopeがpatternのときは必須です。
レスポンス · 200
{
  "matchCount": 12,
  "totalEvaluated": 418,
  "matchingGroupKeys": ["utgr_5d0e2b77", … ],
  "sampleMatches": [
    {
      "groupKey": "utgr_5d0e2b77",
      "merchantName": "Blue Bottle Coffee",
      "amount": -6.25,
      "currency": "USD",
      "transactionDate": "2026-09-12"
    },
    …
  ]
}

ルールを変更する

ルールの定義を、送った内容で置き換えます。変更する項目だけでなく、残したい項目もすべて送ってください。パスのruleIdはルール一覧が返すidで、versionは最後に読み込んだものである必要があります。Eraのライブラリのルールで変更できるのはuserOverridesだけです。それ以外は、一覧が返したとおりに送り返してください。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのルールと取引だけで、銀行側では何も変わりません。

PUT/banking/rules/{ruleId}
必要なスコープbanking:write
リクエストボディ
version任意
最後に読み込んだときのルールのバージョンです。ルールの現在のバージョンと一致しないと、呼び出しは409で拒否されます。省略してもチェックは省かれず、失敗します。
ruleName
ルールの名前です。
description任意
ルールの用途についての任意のメモです。
priority任意
ほかのルールの中でこのルールが実行される位置です。高いものが先に実行され、二つのルールが一つの取引に同じ項目を設定しようとした場合は、高いほうが優先されます。デフォルトは0です。
filters
条件です。型付きフィルターオブジェクトのリストで、それぞれtypeフィールドで種類を示します。取引はすべての条件を満たす必要があります。別の組み合わせにしたい場合は、and、or、notのフィルターを入れ子にしてください。最低一つ必要です。口座の種類を指定したaccount_typeフィルターはパターンルールでのみ使えます。取引ルールでは400で拒否されます。
actions
ルールに一致した取引それぞれに何をするかです。型付きアクションオブジェクトのリストで、カテゴリの設定、タグの追加や削除、加盟店名の変更、説明の書き換え、レビューステータスの設定、非表示、振替としてのマークができます。最低一つ必要で、タグのアクションを除き、各種類は一つまでです。各タグはあらかじめ存在している必要があり、一度しか指定できません。
applyRetroactively任意
変更したルールを、すでにある取引に適用し直します。その前に、古いバージョンが取引に行ったことを取り消します。デフォルトはfalseです。
appliesFrom任意
この日付以降の取引だけが対象です。
appliesTo任意
この日付以前の取引だけが対象です。
applicationScope任意
ルールをいつ実行するかです。新しい取引だけならprospective、既存の取引に対して実行するときはretroactive、両方ならbothです。デフォルトはbothです。
userOverrides任意
Eraのライブラリのルールで、調整が許されている設定に対する自分の値です。ルールのパターンと同じ種類の型付きオブジェクトで指定します。自分で作ったルールでは無視されます。
group任意
ルールを分類するグループで、作成時と同じリストから選びます。変更は定義全体を置き換えるので、省略するとルールのグループは外れます。残したい場合は現在のグループを送ってください。Eraのライブラリのルールでは、省略するか、すでに付いているグループを送ってください。
レスポンス · 200
{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

retroactiveStatusは、既存の取引にルールを適用する、またはルールが行ったことを取り消すよう呼び出しで求めた場合を除き、nullです。completedはその処理がレスポンスの前に終わったこと、in_progressはまだ実行中でaffectedTransactionCountが確定していないこと、queue_fullはキューが満杯で処理が始まらなかったこと(ルール自体の変更は保存されています)、partial_successは一部しか通らなかったこと(一部の変更が保存されなかった、または処理の一部しかキューに入らなかった)を表します。

ルールをオンにする

ルールをもう一度オンにして、新しい取引に再び適用されるようにします。すでにオンのルールをオンにしても何も変わりません。Eraのライブラリのルールも、自分のルールと同じようにオン・オフできます。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのルールと取引だけで、銀行側では何も変わりません。

POST/banking/rules/{ruleId}/enable
必要なスコープbanking:write
クエリパラメータ
version任意
最後に読み込んだときのルールのバージョンです。省略するとチェックを省きます。送った場合、それ以降にルールが変わっていれば、呼び出しは409で拒否されます。
レスポンス · 200
{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

ルールをオフにする

ルールをオフにして、新しい取引に適用されないようにします。定義はそのまま残り、すでに行った変更も、revert_retroactivelyで取り消しを求めない限り残ります。すでにオフのルールをオフにしても、オフのままです。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのルールと取引だけで、銀行側では何も変わりません。

POST/banking/rules/{ruleId}/disable
必要なスコープbanking:write
クエリパラメータ
version任意
最後に読み込んだときのルールのバージョンです。省略するとチェックを省きます。送った場合、それ以降にルールが変わっていれば、呼び出しは409で拒否されます。
revert_retroactively任意
ルールがすでに取引に適用したカテゴリ、タグ、その他の変更も取り消します。デフォルトはfalseで、その場合それらの変更は残ります。
レスポンス · 200
{
  "rule": { … },
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

retroactiveStatusは、既存の取引にルールを適用する、またはルールが行ったことを取り消すよう呼び出しで求めた場合を除き、nullです。completedはその処理がレスポンスの前に終わったこと、in_progressはまだ実行中でaffectedTransactionCountが確定していないこと、queue_fullはキューが満杯で処理が始まらなかったこと(ルール自体の変更は保存されています)、partial_successは一部しか通らなかったこと(一部の変更が保存されなかった、または処理の一部しかキューに入らなかった)を表します。

ルールを削除する

ルールを完全に削除します。ルールを失わずに止めたい場合は、代わりにオフにしてください。パスのruleIdはルール一覧が返すidで、versionは最後に読み込んだものである必要があります。Eraのライブラリのルールは削除できず、オフにすることしかできません。banking:readではなくbanking:writeが必要ですが、変わるのはEraにあるあなたのルールと取引だけで、銀行側では何も変わりません。削除でrevert_retroactivelyを求められるのは一度きりです。queue_fullが返ってきた時点でルールはもう削除されており、再試行する対象が残っていません。ルールを削除し、その影響も取り消したい場合は、まずrevert_retroactivelyを付けてオフにし(受け付けられるまで繰り返せます)、それから削除してください。

DELETE/banking/rules/{ruleId}
必要なスコープbanking:write
クエリパラメータ
version任意
最後に読み込んだときのルールのバージョンです。ルールの現在のバージョンと一致しないと、呼び出しは409で拒否されます。省略してもチェックは省かれず、失敗します。
revert_retroactively任意
ルールがすでに取引に適用したカテゴリ、タグ、その他の変更も取り消します。デフォルトはfalseで、その場合それらの変更は残ります。
レスポンス · 200
{
  "success": true,
  "retroactiveStatus": null,
  "affectedTransactionCount": 0
}

retroactiveStatusは、既存の取引にルールを適用する、またはルールが行ったことを取り消すよう呼び出しで求めた場合を除き、nullです。completedはその処理がレスポンスの前に終わったこと、in_progressはまだ実行中でaffectedTransactionCountが確定していないこと、queue_fullはキューが満杯で処理が始まらなかったこと(ルール自体の変更は保存されています)、partial_successは一部しか通らなかったこと(一部の変更が保存されなかった、または処理の一部しかキューに入らなかった)を表します。

Era Financial Advisors LLCはSEC登録投資顧問会社です(CRD #334404)。登録は特定の技能や研修レベルを意味するものではありません。投資顧問サービスは裁量型かつAI支援によるものであり、個別のファイナンシャルアドバイスに代わるものではありません。証券仲介・カストディサービスはFINRA/SIPC加盟の別法人であるAlpaca Securities LLCが提供しています。Era ThesisおよびEra Agencyの口座は現在、米国居住者のみ開設いただけます。Era Contextは米国、英国、カナダ、フランス、ドイツ、スペインをはじめ計40か国以上の口座に接続できます。本ウェブサイトのいかなる記載も、有価証券の売買の勧誘ではありません。過去のパフォーマンスは将来の成果を保証するものではありません。投資前に当社のForm ADVおよびForm CRSをご確認ください。

App StoreからダウンロードGoogle Play で手に入れよう
era© 2026 Tinwell Labs Inc. DBA Era