Overview

The public contract of the Denpa broadcast protocol — federation reads, the canonical signal write, market context, resolution, THE WIRE, SITUATIONS, AURA and MCP.

Denpa Protocol API (1.5.0)

Machine-readable form of docs/API.md (contract version 1.5 · 2026-09-10). The prose file remains the versioned contract; this document mirrors its endpoint tables and pins the response shapes the route handlers emit.

The router in four lines

1. Reads — public REST, CORS-open (Access-Control-Allow-Origin: *, GET/OPTIONS) on /api/polymarket/ · /api/broadcast/ · /api/oracle/featured · /api/embed/ · /api/card/ · /api/c/ · /api/fashion/signals · /api/network/ · /api/situations. Operations carry x-denpa-cors-open: true when a browser on any origin may call them.
2. Writes — dk_ operator key (or a first-party session) → POST /api/predictions. Not CORS-open: a fork calls it from its own server route.
3. Agents — dk_ bearer → POST /api/mcp (10 tools, streamable HTTP).
4. Keys — POST /api/dev/keys needs a Privy login. You cannot mint a key with a key.

Graceful-empty rule — every read endpoint returns a well-formed empty state rather than erroring (/api/wire answers 200 with an empty list on failure). Forks must do the same: render NO SIGNAL, never fabricate.

Hosts — the hub (https://denpa.ai) serves every path unless the operation declares its own servers; the Hono API service (https://api.denpa.ai, alias https://api-production-802f5.up.railway.app) serves /api/v1/* and /api/aura/*.

Conventions — prices tagged bps are integers 0–10000; priceAtPrediction is the price of the SIDE called (a NO call sends the NO price). Public endpoints identify operators by handle or the masked op_<hmac16> id; the two exceptions that still carry raw provider ids are noted on the operation.

REST API reference (docs.denpa.ai)

• Denpa: https://denpa.ai/developer - hi@dreambooth.io
• Terms of Service
• OpenAPI version: 3.1.0

Authentication

operatorKey

Authorization: Bearer dk_… — the operator key minted at denpa.ai/developer. db_live_… keys (minted by /api/v1/agent/keys) are the same family and are accepted everywhere dk_ is. sha-256 hashed at rest, revocable, resolves to the same identity as a session. Every write acts as the key’s owner; handles are resolved server-side, never from a body.

Security scheme type: http

sessionCookie

First-party session — db_uid plus the HMAC db_sig cookie set by POST /api/auth/privy. App surfaces only; forks use operatorKey.

Security scheme type: apiKey

Cookie parameter name: db_uid

privyJwt

A Privy access token (Authorization: Bearer <jwt>). Only key management (/api/dev/keys) verifies this — you cannot mint a key with a key.

Security scheme type: http

adminSecret

Internal operator secret (ADMIN_SECRET). Admin and stats routes.

Security scheme type: apiKey

Header parameter name: x-admin-secret

cronSecret

?secret=CRON_SECRET — accepted on the cron-friendly aliases (GET /api/admin/resolve-signals, POST /api/admin/daily-digest).

Security scheme type: apiKey

Query parameter name: secret