One endpoint, four modes.

1. API key

When to use. The traditional path. A developer with a card on file. Long-lived service-to-service auth where one tenant owns the bill.

Setup. Generate a key in the dashboard. Store it as DEEPTAP_API_KEY. Pass as Authorization: Bearer ....

curl -X POST https://api.deeptap.ai/v1/search \
  -H "Authorization: Bearer dt_live_..." \
  -H "Content-Type: application/json" \
  -d '{"query": "...", "depth": 1}'

2. x402, machine-to-machine micropayment

When to use. Machine-to-machine commerce. The calling agent has no pre-arranged contract, has no API key, and is willing to pay per call. Built on the HTTP 402 Payment Required flow.

Setup. The calling agent invokes the endpoint with no auth. DeepTap responds 402 with payment instructions. The agent settles, retries with the receipt, and the call proceeds.

# 1. Initial call
POST https://api.deeptap.ai/v1/search
Content-Type: application/json
{"query": "...", "depth": 1}

# 2. DeepTap responds 402
HTTP/1.1 402 Payment Required
WWW-Authenticate: x402 amount={{TBD-depth-1-price}} chain=... receiver=...

# 3. Agent settles and retries
POST https://api.deeptap.ai/v1/search
X-402-Receipt: <signed receipt>
{"query": "...", "depth": 1}

x402 mode bypasses the dashboard entirely. The agent pays per call, receives the response, and the receipt carries enough provenance for downstream reconciliation.

3. MPP, multi-party payment

When to use. A flow where more than one party pays. In DeepTap's context: a primary agent calling DeepTap on behalf of a downstream user where the user covers part of the cost (per-query budget, daily allowance, sponsor pays the rest). MPP also covers the inverse case where DeepTap is one of several services in a composed agent flow and each service settles separately.

Setup. The calling agent presents an MPP envelope listing the paying parties, their share, and the signed authorizations. DeepTap validates the envelope, charges the parties in their published share, and returns the response with one receipt per party.

POST https://api.deeptap.ai/v1/search
Authorization: MPP envelope=<base64>
{
  "query": "...",
  "depth": 2
}

# Response includes per-party receipts
{
  "receipts": [
    { "party": "user_42", "credits": 1, "share": "0.5" },
    { "party": "sponsor_acme", "credits": 1, "share": "0.5" }
  ],
  "facts": [ /* ... */ ]
}

MPP is the right mode when the cost model is more complex than "one tenant pays everything" but simpler than running an internal billing pipeline.

4. TrueCom-signed receipts

When to use. When the agent's downstream consumers need cryptographic provenance for the call. Regulated workflows, agentic commerce that crosses jurisdictional lines, audit-heavy deployments. TrueCom-signed receipts give the receipt itself the integrity of the underlying transaction.

Setup. Auth as API key, x402, or MPP, and add the X-TrueCom-Sign: required header. DeepTap returns the response and a TrueCom-signed receipt that can be verified offline against the published TrueCom public key.

POST https://api.deeptap.ai/v1/search
Authorization: Bearer dt_live_...
X-TrueCom-Sign: required
{"query": "...", "depth": 1}

# Response with TrueCom-signed receipt
{
  "facts": [ /* ... */ ],
  "truecom_receipt": {
    "issuer": "deeptap",
    "issued_at": "2026-04-24T12:34:56Z",
    "claim": "search_call_consumed",
    "credits": 1,
    "signature": "ed25519:..."
  }
}

The receipt verifies offline. No callback to DeepTap is required for downstream audit. See TrueCom for the receipt schema.

Picking a mode