Common Flows

Complete, working code examples for the most common Dakota API integration patterns.

Critical Concepts to Understand

Prerequisites and Dependencies

Before calling Dakota APIs, understand these mandatory requirements:

To Create	You Must First Have
Recipient	Customer with `kyb_status: "approved"`
Destination	Recipient
Onramp Account	Destination (crypto type) + Customer with `kyb_status: "approved"`
Offramp Account	Destination (bank type) + Customer with `kyb_status: "approved"`
Wallet	Signer Group
Signer Group	ES256 public keys (see key generation below)

KYB Approval is Required: Customers must complete KYB verification and have kyb_status: "approved" before you can create onramp accounts, offramp accounts, or process transactions. Attempting these operations with pending/in_progress KYB will fail with customer_not_approved.

Validation Rules

Field	Constraint
`customer.name`	3-100 characters
`recipient.name`	Must be unique per customer (no duplicates)
`recipient.address.street1`	Required
`recipient.address.city`	Required
`recipient.address.country`	Required (ISO 3166-1 alpha-2, e.g., “US”, “DE”)
`destination.crypto_address`	Must be valid for the network (EVM: 0x + 40 hex chars, Solana: base58)

Ownership Model

Dakota uses client isolation - you can only access your own resources:

You can only view/modify customers you created
You can only view/modify recipients belonging to your customers
You can only view/modify destinations belonging to your recipients
Attempting to access another client’s resources returns 403 Forbidden

Required Headers for All POST Requests

Every POST request to Dakota API requires these headers:

-H "X-API-Key: your-api-key"
-H "X-Idempotency-Key: $(uuidgen)"   # REQUIRED for all POST requests
-H "Content-Type: application/json"

Header	Required	Description
`X-API-Key`	All requests	Your API key for authentication
`X-Idempotency-Key`	All POST requests	UUID to prevent duplicate operations. Generate a new UUID for each request.
`Content-Type`	Requests with body	Must be `application/json`

Missing X-Idempotency-Key on POST requests will fail.

ID Types - Do Not Confuse These

Dakota uses different ID types that are NOT interchangeable:

ID Type	Created By	Used For	Example
`wallet_id`	`POST /wallets`	Querying balances, wallet management	`2Nq8G7xK9mR4Ls6DyJ1Uf3Tp`
`destination_id`	`POST /recipients/{id}/destinations`	Onramp, offramp, transactions	`31TgvySz1ARnqMZUdbuxykqqxGV`
`recipient_id`	`POST /customers/{id}/recipients`	Creating destinations	`31TgvwFzi3rstV0DEDzQtuBfwFR`
`customer_id`	`POST /customers`	All operations for that customer	`31Tgw0zSyDVo4Az66kmzUjMuwxx`
`signer_group_id`	`POST /signer-groups`	Creating wallets	`2Nq8H8yL0nS5Mt7EzK2Vg4Uq`

Common Mistake: Using a wallet_id as a destination_id will return destination_not_found error.

Scenario 1: Creating a Wallet (Non-Custodial)

Wallets require signer groups to be created first. The signer_groups field takes an array of signer group IDs (strings), not objects.

Public Key Format Requirements

The member_keys array requires ECDSA P-256 (ES256) public keys in the following format:

Algorithm: ECDSA with P-256 curve (also known as secp256r1 or prime256v1)
Encoding: PKIX/SPKI DER format, then Base64 encoded
Key Type: ES256 (or WEBAUTHN for passkey-based keys)

Generating ES256 Keys

JavaScript (Web Crypto API):

async function generateES256KeyPair() {
  const keyPair = await crypto.subtle.generateKey(
    { name: "ECDSA", namedCurve: "P-256" },
    true,  // extractable
    ["sign", "verify"]
  );

  // Export public key in SPKI format
  const publicKeyBuffer = await crypto.subtle.exportKey("spki", keyPair.publicKey);
  const publicKeyBase64 = btoa(String.fromCharCode(...new Uint8Array(publicKeyBuffer)));

  // Export private key (store securely - never send to server)
  const privateKeyBuffer = await crypto.subtle.exportKey("pkcs8", keyPair.privateKey);
  const privateKeyBase64 = btoa(String.fromCharCode(...new Uint8Array(privateKeyBuffer)));

  return { publicKeyBase64, privateKeyBase64 };
}

// Usage
const { publicKeyBase64, privateKeyBase64 } = await generateES256KeyPair();
// Send publicKeyBase64 to Dakota API
// Store privateKeyBase64 securely on client side

Node.js:

const crypto = require('crypto');

function generateES256KeyPair() {
  const { publicKey, privateKey } = crypto.generateKeyPairSync('ec', {
    namedCurve: 'P-256'
  });

  // Export public key in SPKI/DER format, then base64 encode
  const publicKeyDer = publicKey.export({ type: 'spki', format: 'der' });
  const publicKeyBase64 = publicKeyDer.toString('base64');

  // Export private key (store securely)
  const privateKeyDer = privateKey.export({ type: 'pkcs8', format: 'der' });
  const privateKeyBase64 = privateKeyDer.toString('base64');

  return { publicKeyBase64, privateKeyBase64 };
}

Python:

from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import serialization
import base64

def generate_es256_keypair():
    private_key = ec.generate_private_key(ec.SECP256R1())
    public_key = private_key.public_key()

    # Export public key in SPKI/DER format, then base64 encode
    public_key_der = public_key.public_bytes(
        encoding=serialization.Encoding.DER,
        format=serialization.PublicFormat.SubjectPublicKeyInfo
    )
    public_key_base64 = base64.b64encode(public_key_der).decode('utf-8')

    # Export private key (store securely)
    private_key_der = private_key.private_bytes(
        encoding=serialization.Encoding.DER,
        format=serialization.PrivateFormat.PKCS8,
        encryption_algorithm=serialization.NoEncryption()
    )
    private_key_base64 = base64.b64encode(private_key_der).decode('utf-8')

    return public_key_base64, private_key_base64

Go:

import (
    "crypto/ecdsa"
    "crypto/elliptic"
    "crypto/rand"
    "crypto/x509"
    "encoding/base64"
)

func generateES256KeyPair() (string, string, error) {
    privateKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
    if err != nil {
        return "", "", err
    }

    // Export public key in PKIX/SPKI format
    pubKeyBytes, err := x509.MarshalPKIXPublicKey(&privateKey.PublicKey)
    if err != nil {
        return "", "", err
    }
    publicKeyBase64 := base64.StdEncoding.EncodeToString(pubKeyBytes)

    // Export private key
    privKeyBytes, err := x509.MarshalECPrivateKey(privateKey)
    if err != nil {
        return "", "", err
    }
    privateKeyBase64 := base64.StdEncoding.EncodeToString(privKeyBytes)

    return publicKeyBase64, privateKeyBase64, nil
}

Step 1: Create a Signer Group

# Create signer group with ES256 public keys (base64-encoded SPKI format)
curl -X POST https://api.platform.dakota.xyz/signer-groups \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Treasury Team",
    "member_keys": [
      "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    ]
  }'

Response:

{
  "id": "2Nq8H8yL0nS5Mt7EzK2Vg4Uq",
  "client_id": "2Nq8G7xK9mR4Ls6DyJ1Uf3Tp",
  "name": "Treasury Team",
  "members": [
    {
      "id": "2Nq8H9zM1oT6Nu8FzL3Wh5Vr",
      "name": "Signer 1",
      "public_key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...",
      "key_type": "ES256"
    }
  ]
}

Step 2: Create the Wallet Using Signer Group ID

# signer_groups is an array of STRING IDs, NOT objects
curl -X POST https://api.platform.dakota.xyz/wallets \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Main Treasury Wallet",
    "family": "evm",
    "signer_groups": ["2Nq8H8yL0nS5Mt7EzK2Vg4Uq"],
    "policies": []
  }'

CORRECT signer_groups format:

{
  "signer_groups": ["2Nq8H8yL0nS5Mt7EzK2Vg4Uq"]
}

WRONG signer_groups format (causes “value must be a string” error):

{
  "signer_groups": [{"id": "2Nq8H8yL0nS5Mt7EzK2Vg4Uq"}]
}

Response:

{
  "id": "2Nq8I9AM2pU7Ov9GaM4Xi6Ws",
  "client_id": "2Nq8G7xK9mR4Ls6DyJ1Uf3Tp",
  "name": "Main Treasury Wallet",
  "family": "evm",
  "address": "0x742d35Cc6634C0532925a3b8D404fA40b5398Ad2"
}

Wallet Family Options

Family	Description	Address Format
`evm`	Ethereum, Polygon, Arbitrum, Base	`0x...` (42 chars)
`solana`	Solana	Base58 (32-44 chars)

Scenario 2: Setting Up Onramp (Fiat to Crypto)

Key Understanding: Onramp requires a Destination ID, NOT a Wallet ID. You must create the full chain: Customer → Recipient → Destination.

The Complete Flow

Customer (KYB approved) → Already exists
Recipient → Create for the customer
Destination → Create crypto destination under recipient
Onramp Account → Use destination_id from step 3

Step 1: Verify Customer is KYB Approved

curl -X GET https://api.platform.dakota.xyz/customers/31Tgw0zSyDVo4Az66kmzUjMuwxx \
  -H "X-API-Key: your-api-key"

Customer must have "kyb_status": "approved" to create onramp accounts.

Step 2: Create a Recipient

curl -X POST https://api.platform.dakota.xyz/customers/31Tgw0zSyDVo4Az66kmzUjMuwxx/recipients \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Corp Treasury",
    "address": {
      "street1": "123 Main St",
      "city": "San Francisco",
      "region": "CA",
      "postal_code": "94102",
      "country": "US"
    }
  }'

Response:

{
  "data": {
    "id": "31TgvwFzi3rstV0DEDzQtuBfwFR",
    "name": "Acme Corp Treasury",
    "address": { ... }
  }
}

Step 3: Create a Crypto Destination

This is where you specify the wallet address that will receive funds:

curl -X POST https://api.platform.dakota.xyz/recipients/31TgvwFzi3rstV0DEDzQtuBfwFR/destinations \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "destination_type": "crypto",
    "name": "USDC Receiving Wallet",
    "crypto_address": "0x742d35Cc6634C0532925a3b8D404fA40b5398Ad2",
    "network_id": "ethereum-mainnet"
  }'

Response:

{
  "data": {
    "id": "31TgvySz1ARnqMZUdbuxykqqxGV",
    "destination_type": "crypto",
    "name": "USDC Receiving Wallet",
    "crypto_address": "0x742d35Cc6634C0532925a3b8D404fA40b5398Ad2",
    "network_id": "ethereum-mainnet",
    "status": "active"
  }
}

Save this id - this is your destination_id for onramp.

Step 4: Create Onramp Account

Now use the Destination ID (not wallet ID) to create the onramp:

curl -X POST https://api.platform.dakota.xyz/accounts/onramp \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "destination_id": "31TgvySz1ARnqMZUdbuxykqqxGV",
    "source_asset": "USD",
    "destination_asset": "USDC",
    "capabilities": ["ach"]
  }'

Response:

{
  "id": "31TgwOnrampAccountID",
  "bank_account": {
    "account_holder_name": "Acme Corp Treasury",
    "aba_routing_number": "123456789",
    "account_number": "9876543210",
    "account_type": "checking",
    "capabilities": ["ach", "wire"]
  },
  "destination": {
    "destination_type": "crypto",
    "name": "USDC Receiving Wallet",
    "crypto_address": "0x742d35Cc6634C0532925a3b8D404fA40b5398Ad2",
    "network_id": "ethereum-mainnet"
  },
  "destination_asset": "USDC",
  "rail": "ach"
}

Common Onramp Error

Error:

{
  "code": "destination_not_found",
  "message": "Destination not found"
}

Cause: You used a wallet ID instead of a destination ID. Solution: Create a destination first using /recipients/{id}/destinations, then use that destination’s id field.

Scenario 3: Creating an Offramp (Crypto to Fiat)

Step 1: Create a Bank Destination

curl -X POST https://api.platform.dakota.xyz/recipients/31TgvwFzi3rstV0DEDzQtuBfwFR/destinations \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "destination_type": "fiat_us",
    "name": "Business Checking",
    "aba_routing_number": "021000021",
    "account_number": "123456789",
    "account_type": "checking",
    "account_holder_name": "Acme Corporation",
    "bank_name": "Chase Bank",
    "bank_address": {
      "street1": "383 Madison Avenue",
      "city": "New York",
      "region": "NY",
      "postal_code": "10179",
      "country": "US"
    }
  }'

Response:

{
  "data": {
    "id": "31TgvtxUdXi95dUN4M8X1rhSCNS",
    "destination_type": "fiat_us",
    "name": "Business Checking",
    "aba_routing_number": "*****0021",
    "account_number": "*****6789",
    "account_type": "checking",
    "status": "active"
  }
}

Step 2: Create Offramp Account

curl -X POST https://api.platform.dakota.xyz/accounts/offramp \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "destination_id": "31TgvtxUdXi95dUN4M8X1rhSCNS",
    "source_asset": "USDC",
    "source_network_id": "ethereum-mainnet",
    "destination_asset": "USD",
    "rail": "ach"
  }'

Scenario 4: One-Off Transaction

For single transactions where you don’t need a recurring account:

curl -X POST https://api.platform.dakota.xyz/transactions/one-off \
  -H "X-API-Key: your-api-key" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "customer_id": "31Tgw0zSyDVo4Az66kmzUjMuwxx",
    "destination_id": "31TgvtxUdXi95dUN4M8X1rhSCNS",
    "source_asset": "USDC",
    "source_network_id": "ethereum-mainnet",
    "destination_asset": "USD",
    "amount": "1000.00"
  }'

Quick Reference: Required Headers

Header	When Required	Value
`X-API-Key`	All requests	Your API key
`X-Idempotency-Key`	All POST requests	UUID (e.g., from `uuidgen`)
`Content-Type`	Requests with body	`application/json`

Quick Reference: Endpoint Patterns

Customer Flow

POST /customers                              → Create customer, get customer_id
GET  /customers/{customer_id}                → Check KYB status

Recipient & Destination Flow

POST /customers/{customer_id}/recipients     → Create recipient, get recipient_id
POST /recipients/{recipient_id}/destinations → Create destination, get destination_id

Account Creation (Requires destination_id)

POST /accounts/onramp                        → Fiat → Crypto (requires crypto destination)
POST /accounts/offramp                       → Crypto → Fiat (requires bank destination)
POST /accounts/swap                          → Crypto → Crypto (requires crypto destination)

Wallet Flow (Separate from Payment Flow)

POST /signer-groups                          → Create signer group, get signer_group_id
POST /wallets                                → Create wallet using signer_group_ids
GET  /wallets/{wallet_id}/balances           → Check wallet balances

Destination Types Reference

Crypto Destination

{
  "destination_type": "crypto",
  "name": "My USDC Wallet",
  "crypto_address": "0x742d35Cc6634C0532925a3b8D404fA40b5398Ad2",
  "network_id": "ethereum-mainnet"
}

US Bank (ACH) - All Required Fields

{
  "destination_type": "fiat_us",
  "name": "Business Checking",
  "aba_routing_number": "021000021",
  "account_number": "123456789",
  "account_type": "checking",
  "account_holder_name": "Acme Corporation",
  "bank_name": "Chase Bank",
  "bank_address": {
    "street1": "383 Madison Avenue",
    "city": "New York",
    "region": "NY",
    "postal_code": "10179",
    "country": "US"
  }
}

International Bank (IBAN) - All Required Fields

{
  "destination_type": "fiat_iban",
  "name": "European Account",
  "iban": "DE89370400440532013000",
  "bic": "DEUTDEFFXXX",
  "account_holder_name": "Acme GmbH",
  "account_holder_address": {
    "street1": "Friedrichstraße 123",
    "city": "Berlin",
    "postal_code": "10117",
    "country": "DE"
  },
  "bank_name": "Deutsche Bank",
  "bank_address": {
    "street1": "Taunusanlage 12",
    "city": "Frankfurt",
    "postal_code": "60325",
    "country": "DE"
  },
  "assets": ["EUR"],
  "capabilities": ["sepa"]
}

Supported Assets (Tokens)

Asset	Name	Type
`USD`	US Dollar	Fiat
`EUR`	Euro	Fiat
`USDC`	USD Coin	Stablecoin
`USDT`	Tether	Stablecoin
`DKUSD`	Dakota USD	Stablecoin
`ETH`	Ethereum	Native token
`SOL`	Solana	Native token

Payment Rails (Capabilities)

Rail	Description	Supported Assets
`ach`	US ACH transfers	USD
`fedwire`	US Fedwire transfers	USD
`swift`	International SWIFT transfers	USD, EUR
`sepa`	European SEPA transfers	EUR

Supported Networks

Mainnet (Production)

Network ID	Chain	Family
`ethereum-mainnet`	Ethereum	EVM
`polygon-mainnet`	Polygon	EVM
`arbitrum-mainnet`	Arbitrum	EVM
`base-mainnet`	Base	EVM
`optimism-mainnet`	Optimism	EVM
`solana-mainnet`	Solana	Solana

Testnet (Sandbox)

Network ID	Chain	Family
`ethereum-sepolia`	Ethereum Sepolia	EVM
`ethereum-holesky`	Ethereum Holesky	EVM
`base-sepolia`	Base Sepolia	EVM
`arbitrum-sepolia`	Arbitrum Sepolia	EVM
`optimism-sepolia`	Optimism Sepolia	EVM
`polygon-amoy`	Polygon Amoy	EVM
`solana-devnet`	Solana Devnet	Solana
`solana-testnet`	Solana Testnet	Solana

Token Availability by Network

Network	USDC	USDT	DKUSD
`ethereum-mainnet`	Yes	Yes	-
`polygon-mainnet`	Yes	Yes	-
`arbitrum-mainnet`	Yes	Yes	-
`base-mainnet`	Yes	Yes	Yes
`optimism-mainnet`	Yes	Yes	-
`solana-mainnet`	Yes	Yes	-

Troubleshooting Common Errors

Authentication & Headers

Error	Cause	Fix
`401 Unauthorized`	Missing or invalid API key	Include `X-API-Key: your-api-key` header
`400 Bad Request` (missing idempotency)	Missing `X-Idempotency-Key` on POST	Add `X-Idempotency-Key: <uuid>` header
`409 Conflict`	Reused idempotency key for different request	Generate new UUID for each unique request

Customer & KYB Errors

Error	Cause	Fix
`customer_not_found`	Customer ID doesn’t exist	Verify customer was created successfully
`customer_not_approved`	Customer KYB status is not “approved”	Wait for KYB completion or check `kyb_status` field
`customer name must be at least 3 characters`	Name too short	Use 3-100 characters for customer name
`customer name cannot exceed 100 characters`	Name too long	Use 3-100 characters for customer name
`a customer with that name already exists`	Duplicate customer name for your client	Use unique name per customer

Recipient & Destination Errors

Error	Cause	Fix
`recipient_not_found`	Recipient ID doesn’t exist or belongs to another client	Verify recipient exists and you own it
`duplicate_name`	Recipient name already exists for this customer	Use unique recipient name per customer
`destination_not_found`	Using wallet_id instead of destination_id, or destination doesn’t exist	Create destination via `/recipients/{id}/destinations` first
`403 Forbidden`	Trying to access resource owned by another client	You can only access your own resources

Wallet & Signer Errors

Error	Cause	Fix
`field 'signer_groups/0': value must be a string`	Passing objects instead of strings	Use `["id"]` format, not `[{"id": "..."}]`
Invalid public key format	Key not in ES256 SPKI base64 format	Generate key using ECDSA P-256, export as SPKI DER, base64 encode
`signer_group_not_found`	Signer group ID doesn’t exist	Create signer group first via `/signer-groups`

Onramp/Offramp Errors

Error	Cause	Fix
`customer_not_approved`	Customer KYB not complete	Customer must have `kyb_status: "approved"`
`destination_not_found`	Invalid destination_id	Create crypto destination for onramp, bank destination for offramp
`invalid_request` (non-crypto destination)	Using bank destination for onramp	Onramp requires crypto destination type
`invalid_request` (non-bank destination)	Using crypto destination for offramp	Offramp requires fiat_us or fiat_iban destination

General Validation Errors

Error	Cause	Fix
`invalid_identifier`	Malformed KSUID	Ensure ID is valid 27-character KSUID
`invalid_request`	Missing required field or invalid value	Check request body against required fields
`asset_not_found`	Invalid asset symbol	Use valid asset: USD, EUR, USDC, USDT, ETH, etc.
`network_not_found`	Invalid network_id	Use valid network from supported networks list

Documentation

Authentication

Developers

​Common Flows

​Critical Concepts to Understand

​Prerequisites and Dependencies

​Validation Rules

​Ownership Model

​Required Headers for All POST Requests

​ID Types - Do Not Confuse These

​Scenario 1: Creating a Wallet (Non-Custodial)

​Public Key Format Requirements

​Generating ES256 Keys

​Step 1: Create a Signer Group

​Step 2: Create the Wallet Using Signer Group ID

​Wallet Family Options

​Scenario 2: Setting Up Onramp (Fiat to Crypto)

​The Complete Flow

​Step 1: Verify Customer is KYB Approved

​Step 2: Create a Recipient

​Step 3: Create a Crypto Destination

​Step 4: Create Onramp Account

​Common Onramp Error

​Scenario 3: Creating an Offramp (Crypto to Fiat)

​Step 1: Create a Bank Destination

​Step 2: Create Offramp Account

​Scenario 4: One-Off Transaction

​Quick Reference: Required Headers

​Quick Reference: Endpoint Patterns

​Customer Flow

​Recipient & Destination Flow

​Account Creation (Requires destination_id)

​Wallet Flow (Separate from Payment Flow)

​Destination Types Reference

​Crypto Destination

​US Bank (ACH) - All Required Fields

​International Bank (IBAN) - All Required Fields

​Supported Assets (Tokens)

​Payment Rails (Capabilities)

​Supported Networks

​Mainnet (Production)

​Testnet (Sandbox)

​Token Availability by Network

​Troubleshooting Common Errors

​Authentication & Headers

​Customer & KYB Errors

​Recipient & Destination Errors

​Wallet & Signer Errors

​Onramp/Offramp Errors

​General Validation Errors

Common Flows

Critical Concepts to Understand

Prerequisites and Dependencies

Validation Rules

Ownership Model

Required Headers for All POST Requests

ID Types - Do Not Confuse These

Scenario 1: Creating a Wallet (Non-Custodial)

Public Key Format Requirements

Generating ES256 Keys

Step 1: Create a Signer Group

Step 2: Create the Wallet Using Signer Group ID

Wallet Family Options

Scenario 2: Setting Up Onramp (Fiat to Crypto)

The Complete Flow

Step 1: Verify Customer is KYB Approved

Step 2: Create a Recipient

Step 3: Create a Crypto Destination

Step 4: Create Onramp Account

Common Onramp Error

Scenario 3: Creating an Offramp (Crypto to Fiat)

Step 1: Create a Bank Destination

Step 2: Create Offramp Account

Scenario 4: One-Off Transaction

Quick Reference: Required Headers

Quick Reference: Endpoint Patterns

Customer Flow

Recipient & Destination Flow

Account Creation (Requires destination_id)

Wallet Flow (Separate from Payment Flow)

Destination Types Reference

Crypto Destination

US Bank (ACH) - All Required Fields

International Bank (IBAN) - All Required Fields

Supported Assets (Tokens)

Payment Rails (Capabilities)

Supported Networks

Mainnet (Production)

Testnet (Sandbox)

Token Availability by Network

Troubleshooting Common Errors

Authentication & Headers

Customer & KYB Errors

Recipient & Destination Errors

Wallet & Signer Errors

Onramp/Offramp Errors

General Validation Errors