Update account connection
Updates mutable connection fields. Currently supports renaming only.
Authorizations
Authorization method required to allow user to access the api endpoints.
Path Parameters
Body
"My Kraken Trading Account"
Response
"conn_abc123"
"My Utila Account"
utila, kraken, binance, okx, bybit, bitget, gate, kucoin, plaid, squads, altitude, coinbase, realms, wise, safe, hyperliquid, cubist, privy, dfns, anchorage, revolut_business, turnkey, octav, fordefi, coins_ph, fireblocks, pave_bank, quickbooks "utila"
Canonical brand label for type (e.g. okx → OKX, plaid → Bank, gate → Gate.io).
"Utila"
Connection family: account (import Range Accounts) or ledger (bookkeeping).
account, ledger "account"
Non-sensitive public metadata
"2026-01-01T00:00:00.000Z"
Last config edit: creation, rename, or a credential/session refresh. Sync deliberately never touches it, so this is not a freshness signal — read last_synced_at for that.
"2026-01-01T00:00:00.000Z"
When a transaction-sync run last succeeded for this connection, or null if none ever has. Prefer this over updated_at for freshness: on most providers nothing writes updated_at after creation, so it would age forever however often the connection syncs (RNG-5128).
Two caveats before treating it as connection health. Sync is only ever triggered manually (POST /v2/account-connections/transactions/sync); nothing runs it on a schedule (RNG-5155), so an old timestamp means nobody asked, not that anything is wrong. And for the providers served by the transfers endpoint (safe, squads, realms, cubist, privy, turnkey, dfns, altitude) a run returns early without contacting the provider and is still recorded as a success, so the timestamp moves without any data being fetched (RNG-5156).
"2026-01-01T00:00:00.000Z"
Why the most recent transaction sync failed, when the cause is permanent for this connection rather than a transient error worth retrying. Derived from the last failure, so it is null both when there is no such cause and when a later transient failure replaced it.
provider_region_unsupported: the provider does not serve transaction history for this account's country with the credential it was given. Wise is the case this exists for: statement history is behind SCA (PSD2) and a personal API token only reaches it for accounts based in US, CA, AU, NZ, SG or MY. Balances are unaffected and keep syncing, so do not present this as a broken connection or a bad credential.
Deliberately a fixed vocabulary rather than the underlying error: last_sync_error can carry upstream detail and stays ops-only.
provider_region_unsupported "provider_region_unsupported"
Outcome of the most recent sync run, or null before the first one. failed leaves last_synced_at at the last genuinely successful run.
running, succeeded, failed "succeeded"