Skip to main content
The Dakota Platform API is a RESTful API that enables you to programmatically manage customers, wallets, transactions, and money movement. For the public currency reference, authenticated currency discovery, and directional quote flow, read Foreign exchange (FX). Public documentation does not replace customer-specific availability checks.

Quick Start

To start making API requests, you need:
  1. Get Dashboard Access — Contact 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, PUT, and PATCH requests, include an idempotency key. The key must be a valid UUID:
The key is cached for 24 hours. Once the first request has completed successfully, repeating it with the same key inside that window returns the original response instead of running it again. Reusing the key with a different request body returns 422 idempotency-key-reused. Only successful responses are cached, so a failed request stays retryable under the same 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.