Era API

Approving an agent creates a key

When you approve an agent over OAuth, Era makes an API key for it. It lands in the same dashboard list as the ones you make yourself, under a name Era generates from the client's own name.

It carries exactly the scopes you approved on that screen, and nothing else. Revoke it from the dashboard and the agent can't get new access until you approve it again. A token it already has keeps working until it expires, at most an hour.

Writes show up in your activity log, reads don't

Making and revoking a key both show up in your activity log, and so does every tool call an agent makes over MCP. A REST write shows up too — as the change it made, like a tag created or a transaction edited. A REST read adds no entry at all. Era records these entries on every plan, but reading the full log takes Organise or higher — below that you see only the most recent ones. Even on a write, REST keeps no per-request log: what's recorded is the change, not the call, and the entry lands under your account rather than the key that made it.

If you're ever unsure about a key, revoke it. A key you made yourself stops working on REST and MCP from its next request. An agent's key stops getting new access right away, and any token it already has expires within an hour. Making a replacement takes a minute.

Every account you can see, across every connected institution, with the count of the ones left out beside them: excludedAccountCount, split into tierExcludedAccountCount for the accounts your plan's account limit leaves out and userExcludedAccountCount for the ones you've hidden. accountLimit is how many accounts your plan shows at once, across all your connections. accountLimitLift names the cheapest plan with room for every account you haven't hidden, and it's null when your plan leaves nothing out. Each account carries its accountGroupKey — the value the balance endpoint takes in its path — and the connectionId it belongs to, so this is the call to make first. Takes connectionId to narrow to a single connection (the counts narrow with it; accountLimit and accountLimitLift don't), and includeExcluded to bring in the accounts your plan leaves out and the ones you've hidden.

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

On an account you've hidden or your plan excludes, the balance fields come back null rather than zero — null means withheld, not empty. supportsTransactions is null in the same spirit: it means Era can't say, and never that the answer is no. The same goes for the plan fields: if Era couldn't read your plan on that call, tierExcludedAccountCount, userExcludedAccountCount, accountLimit and accountLimitLift all come back null. accountLimit is also null on a plan with no account limit, and accountLimitLift when no plan has more room or when your plan leaves nothing out.

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
}

A hidden account, or one whose connection was severed, still answers 200 — with the balance fields null. A 404 means the account genuinely isn't there, or the key wasn't shaped like one. Watch the visibility field here: it's null when the account is visible, tier_excluded when your plan's account limit leaves it out, user_excluded when you've hidden it, and connection_severed when its connection was cut. For tier_excluded, accountLimit is your plan's limit and accountLimitLift names the cheapest plan with room for every account you haven't hidden, this one included. accountLimitLift is null for every other state, and on connection_severed accountLimit is null too.

Totals across the accounts you can see: totalAssets, totalLiabilities, and netWorthHint, which is the first minus the second. Takes no parameters.

{
  "userId": "7d1c0b93a8e24f60",
  "accounts": [ … ],
  "totalVisibleCount": 6,
  "totalHiddenCount": 2,
  "totalAssets": 48210.75,
  "totalLiabilities": 9327.40,
  "netWorthHint": 38883.35,
  "computedAt": "2026-08-11T09:32:00Z"
}

netWorthHint counts only the accounts in this response, so totalHiddenCount tells you what it's missing: tierExcludedAccountCount of those are left out by your plan's account limit, and userExcludedAccountCount you've hidden yourself. accountLimitLift names the cheapest plan that brings the first kind back, and it's null when there are none. Treat netWorthHint as a starting figure rather than an authoritative net worth.

Your transactions, a page at a time, wrapped in an envelope with the paging counts beside them. Takes page and pageSize (100 is the ceiling), plus optional filters for account, date range, applied rules, and assigned 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
}

Your plan may apply a history-window floor, which hides transactions older than it. That's why the response carries the historyWindow fields: historyWindowApplied tells you a floor actually hid something, historyWindowFloorDate is where it fell, historyWindowHiddenCount is how many rows are behind it, and historyWindowEarliestDate is how far your history really goes. Without them a short result set is indistinguishable from an account with no older transactions. Two of them change what you write: historyWindowHiddenCount can be null even when a floor applied, so read null as unknown rather than zero; and when historyWindowDegraded is true, Era couldn't confirm your plan on that read, so the floor date is a guess rather than a fact. On a confirmed paid read no floor applies and historyWindowApplied comes back false. Your plan's account limit leaves transactions out too: tierExcludedAccountCount is how many of your accounts it keeps out of this read, and userExcludedAccountCount how many you've hidden — both narrowed to the account you filtered to, if any. Both are null when Era couldn't read your plan on that call.

Paging through a long history spends requests. Your plan caps how fast you can call and, on the free plan, how many calls you get a day. Limits has the per-plan figures, the rate-limit headers, and what a 429 tells you.

The whole category taxonomy: every set of categories, with its sub-categories nested inside. The taxonomy is shared, not per-account.

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

Every tag on your account, as one list. No paging — one response returns all of them.

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