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.

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.

​

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 uses test data and simulated transactions. Sandbox: Test API integration without real money or compliance requirements 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

​

Next Steps

Now that you understand Dakota Platform terminology:

1. Review API Concepts - Learn about response formats, pagination, and error handling
2. Set Up Your Environment - Configure API keys and choose sandbox vs production
3. 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.