Skip to main content
POST
Create account or ledger connection

Authorizations

X-API-KEY
string
header
required

Authorization method required to allow user to access the api endpoints.

Body

application/json
name
string
required
type
object
required
utila
object
kraken
object
binance
object
okx
object
bybit
object
bitget
object
gate
object
kucoin
object
plaid
object
squads
object
altitude
object
coinbase
object
realms
object
safe
object
wise
object
hyperliquid
object
cubist
object
anchorage
object
privy
object
dfns
object
revolut_business
object
turnkey
object
octav
object
quickbooks
object
fordefi
object
coins_ph
object
fireblocks
object
pave_bank
object

Response

200 - application/json
id
string
required
Example:

"conn_abc123"

name
string
required
Example:

"My Utila Account"

type
enum<string>
required
Available options:
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
Example:

"utila"

provider_display_name
string
required

Canonical brand label for type (e.g. okx → OKX, plaid → Bank, gate → Gate.io).

Example:

"Utila"

kind
enum<string>
required

Connection family: account (import Range Accounts) or ledger (bookkeeping).

Available options:
account,
ledger
Example:

"account"

public_data
object
required

Non-sensitive public metadata

Example:
created_at
string<date-time>
required
Example:

"2026-01-01T00:00:00.000Z"

updated_at
string<date-time>
required

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.

Example:

"2026-01-01T00:00:00.000Z"

last_synced_at
string<date-time> | null
required

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).

Example:

"2026-01-01T00:00:00.000Z"

sync_unavailable_reason
enum<string> | null
required

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.

Available options:
provider_region_unsupported
Example:

"provider_region_unsupported"

sync_status
enum<string> | null
required

Outcome of the most recent sync run, or null before the first one. failed leaves last_synced_at at the last genuinely successful run.

Available options:
running,
succeeded,
failed
Example:

"succeeded"

Last modified on August 5, 2026