> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dakota.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Terminology & Key Concepts

Understanding Dakota Platform terminology is essential for successful API integration. This glossary defines the key concepts and entities you'll encounter throughout the documentation and API.

# Core Entities

## Client

**Your business** - The developer or company integrating with Dakota Platform. This is you, building payment functionality into your application or service.

## Customer

**Your end user** - A business or individual that you (the client) want to process payments for. Customers must complete KYB/KYC verification before processing transactions.

*Example: If you're building an invoicing app, your customers would be the businesses using your app who need to receive crypto payments.*

## Sub-Client

**A customer that has its own customers** - A business customer you designate (at creation) as an intermediary, so that other customers can be grouped underneath it. Use sub-clients when one of your customers is itself a business that serves its own end customers — such as a partner, reseller, or sub-developer.

*Example: You onboard "Partner Corp" as a sub-client; the businesses Partner Corp serves are then onboarded as customers associated with that sub-client. See [Sub-Clients](/documentation/sub-clients).*

## Recipient

**Payment receiver** - A person or entity that will receive payments on behalf of a customer. A single customer can have multiple recipients for different use cases.

*Example: A customer (Acme Corp) might have recipients for "Marketing Department" and "Sales Department" to organize incoming payments.*

## Destination

**Payment endpoint** - The specific account, wallet address, or bank account where funds will be sent for a recipient. Each recipient can have multiple destinations across different networks and assets.

*Example: A recipient might have a USDC destination on Ethereum (0x123...) and a separate USDC destination on Polygon (0xabc...).*

# Account Types & Operations

## Auto Account

**Automated recurring account setup** - A special account configuration that provides funding details for automated, recurring payment processing. Creating an auto account doesn't initiate transactions - it sets up the funding infrastructure. Actual transactions occur when funds are received at the provided addresses.

Auto accounts are Dakota's equivalent of what other platforms call **virtual accounts**: dedicated deposit details (bank account details or a crypto address) that automatically convert and forward whatever arrives to a configured destination.

*Use case: Subscription billing, payroll payments, or scheduled vendor payments.*

## One-off Transaction

**Single payment setup** - Individual transaction configuration that provides funding details for on-demand payments. Creating a one-off transaction doesn't initiate the payment - it generates the funding instructions. The actual transaction happens when funds are sent to the provided address.

*Use case: Invoice payments, ad-hoc purchases, or manual transfers.*

# Transaction Types

## Onramp

**Fiat to crypto conversion** - Converting traditional currency (USD, EUR, etc.) into cryptocurrency or stablecoins. Customers use onramps to fund their crypto activities.

*Flow: USD bank account → USDC wallet*

## Offramp

**Crypto to fiat conversion** - Converting cryptocurrency or stablecoins back into traditional currency. Customers use offramps to cash out their crypto holdings.

*Flow: USDC wallet → USD bank account*

## Swap

**Crypto to crypto exchange** - Converting one cryptocurrency or stablecoin into another without touching fiat currency. This enables portfolio management and asset optimization.

*Flow: ETH → USDC, or USDC → USDT*

# Compliance & Verification

## KYB (Know Your Business)

**Business verification process** - Required compliance procedure for business customers. Includes verifying business registration, ownership, financial standing, and regulatory compliance.

*Typical requirements: Certificate of incorporation, bank statements, director identification, beneficial ownership disclosure.*

## KYC (Know Your Customer)

**Individual verification process** - Required compliance procedure for individual customers. Includes identity verification, address confirmation, and risk assessment.

*Typical requirements: Government-issued ID, proof of address, source of funds documentation.*

# Technical Infrastructure

## Provider

**Service integration** - Services that Dakota Platform integrates with to provide specific functionality. Each provider specializes in different aspects of payment processing. Could also be Dakota itself.

## Network

**Blockchain infrastructure** - The underlying blockchain where cryptocurrency transactions are processed.

## Asset

**Currency or token** - Any form of value that can be transferred through the platform. Includes both fiat currencies and cryptocurrencies.

*Examples: USD, EUR (fiat); ETH (crypto); USDC, USDT (stablecoins).*

# API Integration Concepts

## Idempotency

**Safe request retrying** - A mechanism ensuring that the same API request can be made multiple times without creating duplicate resources or side effects. Required for all state-changing operations.

*Implementation: Include a unique `X-Idempotency-Key` header with each POST request. Use UUIDs for guaranteed uniqueness.*

## Webhook

**Real-time notifications** - HTTP callbacks sent by Dakota Platform to your application when specific events occur. Essential for tracking transaction status and KYB/KYC completion.

*Examples: Customer KYB approved, transaction completed, payment failed.*

## Rate Limiting

**Request throttling** - Protective measures that limit how many API requests you can make within a specific time period. Prevents system overload and ensures fair resource usage.

*Typical limits: 300 requests per minute per API key. Exceeded limits return HTTP 429 status.*

# Business Workflow Terms

## External ID

**Your internal reference** - An optional identifier you can assign to Dakota Platform resources (customers, transactions, etc.) to link them with your internal systems.

*Use case: Link Dakota customer ID with your database's user ID for easier reconciliation.*

## Sandbox vs Production

**Development environments** - Separate environments for testing (sandbox) and live operations (production). Sandbox runs against real upstream provider integrations on testnets, with two safeguards: object-create endpoints reject mainnet networks, and per-request `amount` is capped at \$2 USD. The only simulation needed for money movement is `POST /sandbox/simulate/inbound` (mocked inbound deposit) and `POST /sandbox/simulate/onboarding` (KYB/KYC lifecycle). See [Testing](/documentation/testing).

*Sandbox: real provider integrations on testnets, no real money*
*Production: live environment with real transactions and full compliance*

## Status States

**Resource lifecycle tracking** - Standardized status values that indicate where a resource is in its processing lifecycle.

*Common states: pending, in\_progress, completed, failed, requires\_info, approved, rejected.*

# Advanced Concepts

## Multi-signature (Multisig)

**Shared custody control** - A security mechanism requiring multiple cryptographic signatures to authorize transactions. Provides enhanced security for high-value operations.

*Coming soon to Dakota Platform*

## Compliance Monitoring

**Ongoing risk assessment** - Continuous monitoring of transactions and customer activity for suspicious patterns, regulatory compliance, and risk management.

*Automated by Dakota Platform using integrated compliance providers*

## Settlement

**Final transaction completion** - The process of actually moving funds from source to destination after all verification and processing steps are complete.

*Timeline varies by transaction type and network: onramps (1-3 days), crypto transfers (minutes to hours).*

***

# Quick Reference

| Term | Category | Key Point |
| - | - | - |
| Client | Entity | You (the developer/company) |
| Customer | Entity | Your end users who need payments |
| Sub-Client | Entity | A customer that has its own customers under it |
| Recipient | Entity | Who receives payments |
| Destination | Entity | Where payments are sent |
| Onramp | Transaction | Fiat → Crypto |
| Offramp | Transaction | Crypto → Fiat |
| Swap | Transaction | Crypto → Crypto |
| KYB | Compliance | Business verification |
| KYC | Compliance | Individual verification |
| Provider | Technical | Third-party integrations |
| Idempotency | API | Safe request retrying |

# Next Steps

Now that you understand Dakota Platform terminology:

1. **[Review API Concepts](/api-reference/introduction)** - Learn about response formats, pagination, and error handling
2. **[Set Up Your Environment](/documentation/testing)** - Configure API keys and choose sandbox vs production
3. **[Common Flows](/documentation/common-flows)** - Follow our step-by-step implementation guide

Understanding these terms will make the rest of the documentation much clearer and help you communicate effectively with our support team.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.