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"

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_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 July 30, 2026