Skip to main content

​
auth.md

This document describes how autonomous agents authenticate with the Dakota Platform API. It follows the auth.md agent-registration discovery convention. Dakota Platform does not expose an OAuth authorization server for third-party agents. Programmatic access is provisioned through API keys created in the Dakota Platform dashboard. The OAuth metadata files (/.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server) are published as discovery breadcrumbs for compliant scanners and point back to this document via an agent_auth block — but human-initiated API-key provisioning, described below, is the canonical registration flow.

​
Agent audience

  • Resource: https://api.platform.dakota.xyz (production), https://api.platform.sandbox.dakota.xyz (sandbox)
  • Documentation: https://docs.dakota.xyz
  • OpenAPI specification: https://docs.dakota.xyz/openapi.json
  • MCP server: https://mcp.platform.dakota.xyz/mcp (production, HTTPS only)

​
Discovery surface

​
Registration

To provision credentials for an agent, a Dakota Platform account is required.
  1. Request a Dakota Platform account. New customers and partners contact the Dakota team at https://dakota.xyz/talk-to-sales. Existing customers can invite additional users from the dashboard.
  2. Sign in to the dashboard.
  3. Create an API key. Open the API keys section in the sidebar, click Create New API Key, give it a descriptive name (e.g. agent-prod-ingest), and choose its scope. The key value is shown only once — copy it immediately into the agent’s secret store.
  4. Scope the key. Give the agent the smallest scope that it needs. An Operate key moves money, but cannot add recipients, delete anything, or manage users, keys, signers, policies or mandates. It pays an address that is not saved only with the signatures of a wallet signer, or under one of your mandates. A Read only key can only read. See API Key Scopes.
  5. Revocation. Keys can be revoked at any time from the same dashboard view. A key belongs to your organization and keeps working after the person who created it leaves, so revoke the keys you no longer need. Rotate keys on a schedule appropriate to the agent’s blast radius.
There is no machine-to-machine self-service registration endpoint. All key issuance is gated on a Dakota Platform account.

​
Supported authentication methods

API keys are base64-encoded strings, exactly 60 characters (e.g. AHGlPZaxDSMz8Wf1l8VRH4ObdbHiKsWFWnmRyHtiwAc=).

​
Applying credentials

​
REST API

All requests require the x-api-key header:
POST, PUT, and PATCH requests additionally require an x-idempotency-key header containing a unique UUID per request. See API Keys & Headers for full examples in cURL, JavaScript, Python, Go, Rust, and Java.

​
MCP server

Register the Dakota MCP server with your AI client using the API key as a Bearer token:
See MCP Server for client-specific setup (Claude Desktop, Cursor, ChatGPT).

​
Security expectations

  • Transport: HTTPS only. Plain HTTP requests are rejected.
  • Storage: Treat API keys as production secrets. Store them in a secret manager, never in source control.
  • Rotation: Rotate keys when an agent’s deployment changes hands or on a fixed cadence (90 days recommended).
  • Rate limits: See Rate Limiting.
  • Incident response: Compromised keys should be revoked immediately from the dashboard and a new key issued.
For broader guidance, see the Security page.

​
Contact