Skip to main content
Paid article-summary routes support two payment models, split by mount:
  • Wallet mount (/api/v2/x402/...): payment-aware clients use x402 with USDC on Base or Solana, or MPP on Tempo or Stripe (card / Link). A plain request returns HTTP 402, then the client retries with payment credentials. Free browsing routes use a zero-dollar identity proof — the client answers with a wallet proof and no funds move. Account credentials (API key / JWT / OAuth) are rejected with 403 wallet_only.
  • Account mount (plain /api/v2/... routes): API-key and session clients authenticate with Authorization: Bearer pk_drip_... or a session JWT and need an active plan — no credential returns 401, no plan returns 403 subscription_required. There is no free tier. Stock picks, tickers, and writer profiles are included in the plan; paid post reads still debit credits. Wallet credentials are rejected with 403 account_only.
Each first successful paid fetch of a post summary unlocks that post forever for the paying subject. Later fetches of the same post return the live summary with no charge and no new sale. Credits / API key / JWT / MCP OAuth share the same Drip-user entitlement (including in-app chat paid fetches). x402 and MPP clients should store X-Drip-Unlock / unlockToken from the first settle and send it on free re-reads. If the token is lost but the same wallet (x402) or validated MPP credential is presented again, the server detects the existing unlock, skips the charge, and re-issues a token.

​
Response fields

A first API-key post response can report protocol: "mpp" when Drip completes the credit-funded payment through MPP, or "credits" otherwise. The request still spends the authenticated user’s credits. Use the credit ledger to inspect the debit; spendSource is not a response field. Lifetime unlocks apply only to individual posts. Paid stock-picks bundles are charged on each request and do not grant access to their source posts. Stock Picks V2 also offers subscription access; see Stock Picks. Invalid or revoked X-Drip-Unlock does not block payment: when a pay credential is also present, the request falls through to that rail (or to a 402 challenge if none).

​
Wallet identity for free browsing (/api/v2/x402/*)

Free browsing routes take a zero-dollar identity proof instead of payment:
  1. Build a CAIP-122 Sign-In-With-X message for the target origin (domain, URI, version 1, a fresh random nonce, issuedAt, chain eip155:* or solana:*).
  2. Sign it with the wallet key (EIP-191 for EVM, ed25519 for Solana).
  3. Base64-encode the payload and send it in the sign-in-with-x header. Proofs are single-use — sign a fresh message per request, and keep issuedAt within 5 minutes.
MPP wallets can instead answer the zero-amount WWW-Authenticate: Payment challenge with a proof credential. A tampered or replayed proof returns 401 (invalid_siwx / siwx_replayed); unauthenticated calls get 402. Repeated calls from one wallet are rate limited (429 wallet_rate_limited).

​
The 402 handshake for wallet clients

  1. A plain request to a paid route returns 402 with two headers:
    • WWW-Authenticate: Payment ... — the MPP challenges for Tempo and Stripe
    • PAYMENT-REQUIRED — the x402 v2 challenge
  2. Retry the same request through a payment-aware client, or manually with:
    • Authorization: Payment <credential> for MPP, or
    • a PAYMENT-SIGNATURE header for x402 v2.
  3. On success (200), the response includes synthesizedSummary and paymentInfo.
The 402 response lets a wallet-aware client inspect the exact runtime price before authorizing payment. For discovery-time estimates, publication post listings include priceCents. The runtime challenge is authoritative.
Treat a 402 as a “pay and retry” signal, not a failure. If a plain HTTP request returns 402, retry it through the payment-aware client rather than surfacing an error.
A plain request returns a challenge rather than the paid summary:
After a successful payment, the response identifies how the request was paid:

​
API-key credits

API keys are traditional bearer tokens created from the API keys page. Use them when your agent or backend service should spend an account balance instead of holding a wallet.
API keys spend available account credits, using signup credits before top-ups for signed-in accounts. If the balance is too low, the paid route returns 403 with reason: "insufficient_credits" instead of issuing a 402 payment challenge. See the API-key quickstart for the full setup and request examples.

​
Inspect pricing before payment

List a publication’s recent posts to compare prices before selecting one:
priceCents is useful for selection and agent spending limits. When requesting the paid route with a wallet, inspect the returned 402 challenge before authorizing payment because it contains the live price.

​
Discovery pricing vs runtime pricing

The OpenAPI discovery document exposes x-payment-info.offers[] on paid routes. These offers are advisory — they may list Base or Solana USDC (x402), Tempo, and Stripe charges, or catalog floor prices. The runtime 402 challenge is authoritative. Per-post pricing comes from the live challenge, and the price may scale with the request — for example, stock-picks charge a flat rate per UTC day served, so a from/to range costs the day rate × charged days. Always trust the live 402 over publication listings or discovery offers.

​
Status codes

A 404 and a 503 never carry a payment challenge — do not pay on either. 503 means the summary is still being generated; retry shortly.
For production handling, see Errors & Retries.

​
Discovery

Prefer GET /openapi.json (OpenAPI 3.1) for route shapes, JSON schemas, and paid-route x-payment-info.offers[] metadata. If OpenAPI is unavailable, use GET /.well-known/x402 for the paid resource list in METHOD /path form. The root x-discovery.ownershipProofs field is a Drip vendor extension, not part of core MPP discovery.