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

*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: 100 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.