Era API

에이전트를 승인하면 키가 만들어집니다

OAuth로 에이전트를 승인하면 Era가 그 에이전트용 API 키를 만듭니다. 직접 만든 키들과 같은 대시보드 목록에, 클라이언트 이름을 바탕으로 Era가 지은 이름으로 나타납니다.

그 화면에서 승인한 범위만 정확히 지니고, 그 밖의 것은 없습니다. 대시보드에서 폐기하면, 다시 승인할 때까지 에이전트는 새 액세스 권한을 받을 수 없습니다. 이미 가진 토큰은 만료될 때까지, 최대 한 시간 동안 계속 작동합니다.

쓰기는 활동 기록에 남고, 읽기는 남지 않습니다

키를 만들고 폐기하는 일은 둘 다 활동 기록에 남고, 에이전트가 MCP로 하는 모든 도구 호출도 남습니다. REST 쓰기도 남습니다 — 태그를 만들었다, 거래를 수정했다처럼 그 쓰기가 만든 변경으로 기록됩니다. REST 읽기는 항목을 전혀 만들지 않습니다. 이 항목들은 어느 요금제에서나 기록되지만, 기록 전체를 읽으려면 Organize 이상이 필요합니다. 그 아래에서는 가장 최근 항목만 보입니다. 쓰기 항목에는 계정이 기록되며, 변경을 만든 키는 기록되지 않습니다.

어떤 키가 미덥지 않다면 폐기하세요. 직접 만든 키는 다음 요청부터 REST와 MCP에서 작동하지 않습니다. 에이전트의 키는 즉시 새 액세스 권한을 받지 못하고, 이미 가진 토큰도 한 시간 이내에 만료됩니다. 새로 만드는 데는 1분이면 됩니다.

연결된 모든 기관에 걸쳐, 볼 수 있는 계좌를 전부 돌려줍니다. 빠진 계좌가 몇 개인지도 함께 옵니다. 그 수가 excludedAccountCount이고, 요금제의 계좌 한도 때문에 빠진 tierExcludedAccountCount와 직접 숨긴 userExcludedAccountCount로 나뉩니다. accountLimit은 모든 연결을 합쳐 요금제가 한 번에 보여 주는 계좌 수입니다. accountLimitLift는 숨기지 않은 계좌가 모두 들어가는 가장 저렴한 요금제의 이름이고, 요금제 때문에 빠진 계좌가 없으면 null입니다. 계좌마다 잔액 엔드포인트가 경로로 받는 값인 accountGroupKey와, 그 계좌가 속한 connectionId가 함께 담겨 있으니 먼저 이 호출부터 하시면 됩니다. connectionId로 한 연결만 좁힐 수 있고(개수는 함께 좁혀지지만 accountLimit과 accountLimitLift는 그대로입니다), includeExcluded로 요금제 때문에 빠진 계좌와 숨겨 둔 계좌까지 넣을 수 있습니다.

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

숨겨 둔 계좌나 요금제에서 제외된 계좌에서는 잔액 필드가 0이 아니라 null로 옵니다. null은 비었다는 뜻이 아니라 알려 주지 않는다는 뜻입니다. supportsTransactions의 null도 같은 뜻으로, Era가 말할 수 없다는 것이지 답이 아니라는 뜻은 결코 아닙니다. 요금제 필드도 마찬가지입니다. 그 호출에서 Era가 요금제를 읽지 못했다면 tierExcludedAccountCount, userExcludedAccountCount, accountLimit, accountLimitLift가 모두 null로 옵니다. 계좌 한도가 없는 요금제에서는 accountLimit도 null이고, 더 여유 있는 요금제가 없거나 요금제 때문에 빠진 계좌가 없을 때는 accountLimitLift가 null입니다.

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
}

숨긴 계좌도, 연결이 끊긴 계좌도 여전히 200으로 답합니다. 대신 잔액 필드가 null입니다. 404는 그 계좌가 정말로 없거나, 키가 키 형태가 아니었다는 뜻입니다. 여기서는 visibility 필드를 눈여겨보세요. 계좌가 보일 때는 null, 요금제의 계좌 한도 때문에 빠졌을 때는 tier_excluded, 직접 숨겼을 때는 user_excluded, 연결이 끊겼을 때는 connection_severed가 들어갑니다. tier_excluded일 때는 accountLimit이 요금제의 한도이고, accountLimitLift는 이 계좌를 포함해 숨기지 않은 계좌가 모두 들어가는 가장 저렴한 요금제의 이름입니다. 그 밖의 상태에서는 accountLimitLift가 null이고, connection_severed일 때는 accountLimit도 null입니다.

볼 수 있는 계좌들의 합계이며, 기본은 라이브 계좌입니다. totalAssets, totalLiabilities, 그리고 앞의 것에서 뒤의 것을 뺀 netWorthHint가 들어 있습니다. simulationModes를 넘기면 어떤 모드를 셀지 고를 수 있으며, 계좌 목록과 합계는 지정한 모드만 포함합니다. 어떤 모드를 포함했는지는 includedSimulationModes가 모든 응답에서 알려 줍니다. simulationExcludedAccountCount는 모드 때문에 빠진, 볼 수 있는 계좌의 수입니다. totalHiddenCount는 별도의 수치로, 요금제나 직접 설정한 표시 설정 때문에 숨겨진 계좌를 모든 모드에서 세며, simulationModes가 제외한 계좌는 절대 포함하지 않습니다.

{
  "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가 세는 것은 이 응답에 담긴 계좌뿐이며, 무엇이 빠졌는지는 두 수치가 알려 줍니다. simulationExcludedAccountCount는 요청한 모드 밖의 계좌 수입니다. totalHiddenCount는 모든 모드에서 숨겨진 계좌 수입니다. 이 수치는 둘로 나뉩니다. tierExcludedAccountCount는 요금제의 계좌 한도 때문에 빠진 계좌이고, userExcludedAccountCount는 직접 숨긴 계좌입니다. 해당 호출에서 Era가 요금제를 읽지 못했다면 둘 다 null입니다. accountLimitLift는 앞의 계좌들을 되돌리는 가장 저렴한 요금제의 이름이고, 그런 계좌가 없으면 null입니다. netWorthHint는 확정된 순자산이 아니라 출발점이 되는 숫자로 다루세요.

거래를 한 페이지씩, 페이지 수 정보와 함께 감싸서 돌려줍니다. page와 pageSize(최대 100)를 받고, 계좌·기간·적용된 규칙·부여된 태그로 선택적 필터를 걸 수 있습니다.

{
  "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은 0이 아니라 알 수 없음이라는 뜻으로 읽으세요. 그리고 historyWindowDegraded가 true이면 그 조회에서 Era가 요금제를 확인하지 못한 것이므로, 경계 날짜는 사실이 아니라 추정입니다. 요금제가 확인된 유료 조회에서는 경계가 적용되지 않고 historyWindowApplied는 false로 돌아옵니다. 요금제의 계좌 한도 때문에 빠지는 거래도 있습니다. tierExcludedAccountCount는 이 조회에서 한도 때문에 빠진 계좌 수이고, userExcludedAccountCount는 직접 숨긴 계좌 수입니다. 계좌로 필터링했다면 둘 다 그 계좌만 셉니다. 그 호출에서 Era가 요금제를 읽지 못했다면 둘 다 null입니다.

긴 내역을 페이지별로 넘기면 요청이 소모됩니다. 요금제는 호출 속도를 제한하고, 무료 요금제에서는 하루에 쓸 수 있는 호출 수도 제한합니다. 유료 요금제는 공정 사용 원칙에 따라 운영됩니다. 요금제별 수치, 속도 제한 헤더, 그리고 429가 알려주는 내용은 제한 섹션에 있습니다.

카테고리 체계 전체입니다. 카테고리 묶음마다 하위 카테고리가 중첩되어 들어 있습니다. 이 체계는 공용이며 계좌별이 아닙니다.

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

계정의 모든 태그를 한 목록으로 돌려줍니다. 페이지 나눔은 없습니다. 한 번의 응답이 전부를 돌려줍니다.

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

계정의 모든 자동화 규칙입니다. 직접 만든 규칙과 Era가 규칙 라이브러리에서 설정해 준 규칙 모두, 각각의 조건(filters), 하는 일(actions), 켜져 있는지 여부, 그리고 버전을 함께 돌려줍니다. 페이지 나눔은 없습니다. 한 번의 응답이 전부를 돌려줍니다. 꺼진 규칙은 요청하지 않으면 빠집니다.

{
  "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 문서에 나와 있습니다.