Skip to main content
The Dakota Platform API is a RESTful API that enables you to programmatically manage customers, wallets, transactions, and money movement.

Quick Start

To start making API requests, you need:
  1. Get Dashboard AccessContact sales if you don’t have an account yet
  2. Create an API Key — Log into the Dakota Dashboard and navigate to API Keys to create a new key
  3. Make Your First Request — Use your API key with the sandbox base URL
See API Keys & Headers for detailed setup instructions.

API Versioning

The Dakota API uses a stable versioning approach: The API follows semantic versioning principles. Non-breaking changes (new endpoints, optional fields) are added without version changes. Breaking changes will be announced in advance with migration documentation.

OpenAPI Specification

OpenAPI 3.0.3 spec available - The complete machine-readable API specification can be downloaded for SDK generation, Postman import, or AI agent integration.
Use cases:
  • Generate client SDKs in any language (openapi-generator)
  • Import into Postman, Insomnia, or Swagger UI
  • Power AI agents and code generation tools
  • Automated API testing and validation

Base URLs

Start with Sandbox — We recommend building and testing your integration in the sandbox environment first. Sandbox uses simulated data and won’t process real transactions.

Authentication

All API requests require authentication via the x-api-key header:
For POST requests, include an idempotency key:
See API Keys & Headers for details.

Code Examples

The following examples demonstrate common API operations in JavaScript, Python, and Go.

Create a Customer

List Customers with Pagination

Create an Onramp Account

Create a Webhook Target

Rate Limits

Rate limit headers included in every response:
  • X-RateLimit-Limit - Maximum requests allowed in the current one-minute window
  • X-RateLimit-Remaining - Requests remaining in the current window
  • X-RateLimit-Reset - Unix timestamp when the current rate-limit window resets
When a request is throttled (429), responses also include Retry-After with seconds to wait before retrying. See Rate Limiting for handling strategies.

Response Format

All responses are JSON. List responses include pagination:
Pagination parameters:
  • limit - Items per page (default: 20, max: 100)
  • starting_after - Cursor for next page
  • ending_before - Cursor for previous page
Error responses follow RFC 9457 Problem Details format with application/problem+json content type:
See Errors for all error types and handling best practices.

Data Model

The Dakota API is organized around the following core resources and their relationships:

Resource Relationships

Resource Identifiers

All resources use KSUID (K-Sortable Unique Identifier) for IDs:
  • Format: 27-character base62 string (e.g., 2hCjxJzUAW6JVRkZqaF9E0KpM3a)
  • Properties: Lexicographically sortable by creation time, globally unique
  • Usage: Used for pagination cursors (starting_after, ending_before)

Filtering and Sorting

List endpoints support filtering via query parameters. Common patterns:

Customers

Auto Transactions

Applications

Available Filter Parameters

Bulk Operations

The API provides bulk endpoints for specific use cases:

Bulk Risk Rating Calculation

Calculate risk ratings for multiple entities in a single request:
Behavior:
  • Does NOT persist data - calculation only
  • All-or-nothing validation: if any item fails, returns detailed errors for all invalid items
  • Returns risk_rating object with score, level, factors, and more
See the OpenAPI specification for complete request/response schemas.

Pagination Limits

Response Format Details

List Response Structure

All list endpoints return a paginated response:
Fetching the next page:

Error Response Structure

All errors return RFC 9457 Problem Details:
The request_id should be included when contacting support. See Errors for all error types. For complete response schemas and examples, see the OpenAPI specification.