Dino has three public credential patterns. Pick the smallest one that can do the job, and keep secrets out of model prompts, browser bundles, and logs.
#Quick choice
| Credential | Prefix / shape | Best for | Cash | Crypto |
|---|---|---|---|---|
| Dino spending key | din_test_... or din_live_... | An agent or backend that creates governed spend, checkout, or payout requests for one policy profile | Create spend requests, checkout intents, read balance / status | Create and read payout intents; cannot approve |
| Team API key | dba_... (legacy mid_...) | Developer consoles, server-to-server admin jobs, and team-scoped operations | Team reads / writes where scopes allow | Balance reads, approvals, declines, recipient management |
| OAuth / MCP | User grants or host-managed auth | User-facing apps and assistants where the operator should sign in instead of copying secrets | Delegated tools and account access depending on scopes | Delegated crypto tools only when the host exposes the needed scopes |
#Dino spending keys (din_)
Use a spending key when a trusted backend or tool runner needs to create economic actions under a specific policy profile.
din_test_keys are for sandbox cash flows and test money.din_live_keys are for production.- Spending keys are shown once. Store them in a secret manager or server environment variable.
- A spending key is not a card number and not an all-team admin key.
- Spending keys cannot approve crypto payouts.
Typical cash calls:
GET /v1/balancePOST /v1/spend-requestsGET /v1/spend-requests/:idPOST /v1/checkout/intents
Typical crypto calls:
GET /v1/crypto/capabilitiesPOST /v1/crypto/payout-intentsGET /v1/crypto/payout-intents/:idGET /v1/crypto/payout-intents
#Team API keys (dba_)
Use a team API key for team-scoped developer workflows and privileged server-to-server operations. Team keys use explicit scopes such as spend.read and spend.write.
Team API keys are the right fit when you need to:
- approve or decline crypto payout intents from a backend service
- read workspace-scoped crypto balance
- manage saved crypto recipients
- build internal operator tooling
- reconcile team-wide data
Do not hand team keys to agents unless the agent runtime is a trusted backend with a narrow tool surface in front of it.
#OAuth and MCP
Use OAuth or MCP when a user should connect Dino through a browser sign-in instead of copying a raw key. This is usually the best operator experience for user-facing apps and assistant hosts.
OAuth / MCP access is scope-driven. Request only the scopes your integration needs and show the user what the assistant can do. For Solana USDC payment requests, verify the host exposes the crypto payout tools and scopes you need before designing the workflow around them.
#Safe tool boundary
The default architecture is:
- The model plans.
- Your backend validates the request.
- Your backend injects
Authorization: Bearer ...andIdempotency-Key. - Dino returns a policy decision or pending approval state.
- Your backend returns only safe fields to the model.
Never paste din_ or dba_ secrets into prompts, custom instructions, browser JavaScript, or shared transcripts.