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.

​

Sandbox Philosophy

• Onramp — POST /sandbox/simulate/inbound mocks the USD deposit. The follow-on stablecoin transfer to the Destination is a real testnet transaction.
• Offramp — send real testnet crypto to the offramp’s source_crypto_address. The on-chain inbound is real; the USD outbound to the bank Destination is mocked.
• Swap — fully on-chain on testnets, end to end.

• Base URL: https://api.platform.sandbox.dakota.xyz
• Dashboard: https://platform.sandbox.dakota.xyz
• API keys: Base64-encoded strings, generated from the dashboard.

​

Sandbox Restrictions

​

Network Restriction

​

Amount Cap

• POST /transactions/one-off — the amount field. Rejected synchronously with 400 Bad Request.
• POST /sandbox/simulate/inbound — the amount field. Rejected synchronously with 400 Bad Request.
• Auto-account inbound deposits — when a sandbox crypto deposit lands on an auto-account’s source address and the converted USD value exceeds the cap, the auto-account transaction is created and then transitioned to failed with a failure_reason indicating the cap was exceeded. The failure surfaces via the standard transaction.auto.updated webhook (and on GET /auto-transactions/{id}); there is no synchronous rejection because the deposit has already settled on-chain.

​

Simulation Endpoints

​

Simulate an Inbound Payment

# Inbound ACH against an onramp account
curl -X POST https://api.platform.sandbox.dakota.xyz/sandbox/simulate/inbound \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "simulation_id": "sim_onramp_001",
    "type": "ach_inbound",
    "account_id": "2LfZn6LNoSvMGuSQ0pLLxj6BLGR",
    "amount": "1.00",
    "currency": "USD",
    "scenario": "success_immediate"
  }'

• type — ach_inbound or wire_inbound for USD rails.
• account_id — required for ach_inbound and wire_inbound. Use the onramp account ID.
• scenario — success_immediate (default) or success_delayed with a delay_seconds field.
• simulation_id — your idempotency key for the simulation. Repeating the call with the same ID and identical params returns the original response; conflicting params return 409.

​

Simulate an Onboarding Transition

# Approve a customer's KYB
curl -X POST https://api.platform.sandbox.dakota.xyz/sandbox/simulate/onboarding \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "kyb_approve",
    "applicant_id": "01HABCDEFG1234567890XYZ",
    "simulation_id": "sim_kyb_approve_001"
  }'

# Reject KYB with a reason code
curl -X POST https://api.platform.sandbox.dakota.xyz/sandbox/simulate/onboarding \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "kyb_reject",
    "applicant_id": "01HABCDEFG1234567890XYZ",
    "simulation_id": "sim_kyb_reject_001",
    "reason_code": "MISSING_EIN"
  }'

# Request additional information
curl -X POST https://api.platform.sandbox.dakota.xyz/sandbox/simulate/onboarding \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "kyb_info_request",
    "applicant_id": "01HABCDEFG1234567890XYZ",
    "simulation_id": "sim_kyb_info_001",
    "info_request_fields": ["ssn", "address"]
  }'

​

Tracking Simulation State

• GET /sandbox/simulations/{simulation_id} — returns current state and the callback delivery history.
• POST /sandbox/simulations/{simulation_id}/advance — unpauses with action release, reject, approve, etc. (valid actions vary per scenario).

​

Sandbox Behavior Control Headers

​

Available Headers

# Apply a preset scenario and skip the manual advance step
curl -X POST https://api.platform.sandbox.dakota.xyz/transactions/one-off \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "X-Sandbox-Scenario: insufficient_funds" \
  -H "X-Sandbox-Instant-Completion: true" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

# Inject a bespoke 503 at the provider_call step
curl -X POST https://api.platform.sandbox.dakota.xyz/transactions/one-off \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "X-Sandbox-Error-Status: 503" \
  -H "X-Sandbox-Error-Message: Provider degraded" \
  -H "X-Sandbox-Error-Step: provider_call" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

​

Scenarios

​

TRM Compliance Mock Patterns

# Create a destination using a high-risk-classified address
curl -X POST https://api.platform.sandbox.dakota.xyz/recipients/$RECIPIENT_ID/destinations \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "network": "ethereum-sepolia",
    "address": "0xBAD0000000000000000000000000000000000000"
  }'

​

Webhook Testing

​

ngrok for Local Development

# Expose your local server
ngrok http 3000

# Register the HTTPS tunnel as a webhook target
curl -X POST https://api.platform.sandbox.dakota.xyz/webhooks/targets \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://abc123.ngrok.io/webhooks", "active": true}'

​

Webhook.site for Quick Testing

1. Visit https://webhook.site and copy the unique URL.
2. Register it as a webhook target.
3. Trigger a simulation; observe the live deliveries.

​

Required Headers

curl -X POST https://api.platform.sandbox.dakota.xyz/customers \
  -H "X-API-Key: $DAKOTA_API_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{...}'

​

Rate Limit Testing

for i in {1..150}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    https://api.platform.sandbox.dakota.xyz/customers \
    -H "X-API-Key: $DAKOTA_API_KEY" &
done
wait

​

Common Issues

​

HTTP 400 on object create with a *-mainnet network

​

HTTP 400 on a one-off transaction or simulate inbound with amount > 2.00

​

HTTP 400 on POST requests in general

​

Webhooks not received

​

Transactions stuck in processing

​

Migration to Production

1. Update configuration — change the base URL to https://api.platform.dakota.xyz and replace sandbox API keys with production keys. Update webhook URLs to your production receiver.
2. Environment variables
   DAKOTA_API_KEY=your_production_api_key
   DAKOTA_BASE_URL=https://api.platform.dakota.xyz
   DAKOTA_PUBLIC_KEY=your_production_webhook_public_key
   
3. Switch network IDs — replace testnet IDs (*-sepolia, *-amoy, *-devnet) with their mainnet counterparts. Production rejects testnet IDs.
4. Remove cap-imposed amount limits — the $2 cap is sandbox-only. Use real transaction amounts in production.
5. Roll out gradually — start with low-value transactions, monitor error rates, and have a rollback plan.

​

Next Steps

• Authentication — production security practices.
• Customer Onboarding — production KYB flows.
• Common Flows — onramp, offramp, swap, and wallet flows end-to-end.
• Webhooks — webhook signature verification and event reference.

​

API Reference

• Simulate an Inbound Payment Event
• Simulate an Onboarding State Transition
• Get Simulation Status
• Advance a Paused Simulation
• List Available Simulation Scenarios