Skip to main content
Connections configure integration sources in your workspace. Use the shared quickstart for API authentication and the workspace data model for account ownership and identifiers.

Connection families

GET /v2/account-connections defaults to kind=account. Request each other kind explicitly when listing those families. Creation uses POST /v2/account-connections: type selects the provider; for type: custom, kind selects account or books. Account preview applies to account providers, not the other families.

Read the capability inventory

The tables and JSON inventory are generated from the same dataset. Capability state and verification are separate: Provider registration and credential fields alone do not establish discovery, balance, or history support. Source-backed records describe inspected implementation, not a successful vendor call. A live-tested record must name its date and evidence independently. Authentication cells name credential fields, never values. Unless a start operation is listed, supply the named credential object in the connection-creation request. For complete bodies, optional fields, and provider-specific operations, use the API reference. A supported state does not promise availability for every region, account, asset, or credential, or any history-retention window. No provider capability in this inventory has been live-tested for this page.

account providers

ledger providers

risk providers

travel_rule providers

Custom connection

The custom provider accepts kind: account (the default) or kind: books for client statements, with no vendor credentials. For kind: account, your application supplies its accounts, balance snapshots, and movements through the custom-ingestion endpoints. Its preview echoes already-saved accounts; it does not discover upstream accounts. Balance refresh does not pull or replace client-pushed holdings. Use the synthetic custom-account inputs and retain the IDs returned by your requests. Pushing movements alone does not establish transaction-sync coverage for reconciliation. Read the response coverage and freshness fields before using a reconciliation result.

Verification and maintenance

The JSON includes per-field verification records with method (source-backed or live-tested), date, and evidence. Unknown capability cells remain unknown even when family or authentication evidence exists. Balance source is recorded separately from whether balances are supported. The Range API documentation maintainers refresh the inventory when provider code, credentials, routing, or observed behavior changes. Source-backed verification records pin the inspected revision. Dates change only when that field is checked again. Regeneration and an offline drift test keep the page and JSON aligned; they do not perform vendor calls. For provider failures and retry decisions, see Errors and rate limits.
Last modified on November 10, 2026