The default pattern for LLM-driven money movement in Dino is:
agent runtime → customer-owned constrained tool/server → Dino REST /v1
The model plans; your tool runner injects Authorization: Bearer din_… (or a scoped team API key) and Idempotency-Key on creates. Never put raw keys in prompts, custom instructions, or client-only code.
Starter: Agent integration starter — runnable shell + harness with the key on the server.
#Core rule
- The user asks in natural language (“buy X”, “send USDC to …”, “check status”).
- A narrow tool validates arguments and calls Dino.
- Dino enforces policy, budgets, approvals, and ledger rules.
- Operators retain control in the Dino dashboard (pause, revoke, approve).
#Choose your /v1 flow
Same security boundary for all; pick the API that matches the job.
For which product path to choose first (MCP and browser sign-in vs dashboard “copy instructions” vs human-only flows), see Agent spend paths (crypto & cash).
#A) Direct spend (policy + ledger)
For a governed decision without a checkout card from Dino: POST /v1/spend-requests, then webhooks (spend_request.*) and/or GET /v1/spend-requests/:id.
#B) Buy online (purchase intent + credential)
For checkout with optional one-time credential: POST /v1/checkout/intents → authorize → issue-credential; track with purchase_intent.* webhooks or GET /v1/checkout/intents/:id.
#C) Solana USDC payout
For send USDC on Solana from workspace custody: POST /v1/crypto/payout-intents with Idempotency-Key. Approvals use a team API key or dashboard (approve / decline); spending keys alone cannot approve. Track with crypto_payout.* webhooks and/or GET /v1/crypto/payout-intents/:id (see payload notes in the crypto doc).
→ Crypto Payouts API — Solana USDC
#Recommended tool shapes (keep them small)
Flow A — spend
create_spend(amount_cents, currency, merchant_name, reason, idempotency_key?)get_balance()·get_spend(id)
Flow B — checkout
create_purchase_intent(…)·authorize_purchase_intent(…)·get_purchase_intent(id)
Flow C — crypto
create_crypto_payout_intent(amount_atomic, recipient_address, reason?, merchant_name?, idempotency_key?, metadata?)get_crypto_payout_intent(id)· optionallist_crypto_payout_intents/get_crypto_capabilities
The runner adds Authorization and Idempotency-Key; the model does not handle headers.
#Idempotency
Use one stable idempotency key per logical user intent for every creating POST, and reuse it on retries. Do not generate a new random key per retry—that can duplicate spends or payouts.
#What not to do
- Paste card numbers, CVVs, or wallet seeds into chat
- Paste
din_…keys into the model or shared transcripts - Treat prompt text as your security boundary
#MCP and other shells
ChatGPT, Claude, Cursor, and MCP are fine outer layers if the chain stays:
assistant → constrained tool → Dino API
For MCP tool ideas (treasury snapshot, spend status), see Assistant and MCP Integration.
#Handling needs_approval
Use webhooks first (spend_request.*, purchase_intent.*, or crypto_payout.*); poll the matching GET detail route if you must. Register endpoints under Developer → Webhooks.