Boost Boss documentation
Boost Boss has four publisher integration methods, plus a comprehensive API reference for advertisers and integrators. Pick the path that matches what you've built — same backend, same payouts.
Publisher integration methods
Three SDKs and one API, all under the Lumi family name. Each integration matches a different deployment surface — pick the one(s) that match what you ship.
For MCP server developers
Three lines, one tool handler. npm install @boostbossai/lumi-mcp. Works with Claude Desktop, Cursor, Cline, Continue, Zed, Windsurf.
For AI apps and websites
One <script> tag, zero backend changes. boostboss.ai/lumi.js. Async, framework-agnostic, theme-able via CSS variables.
For Chrome / Edge / Firefox extensions, Electron, Tauri
Manifest v3 native, runs in service workers and content scripts. npm install @boostbossai/lumi-sdk. React + Vue subpath bindings included.
For Discord / Telegram / Slack AI bots
Server-side POST /v1/ad-request + bearer auth. Optional helper libraries (lumi-discord, lumi-telegram, lumi-slack) — convenience wrappers, not standalone SDKs.
Common concepts
Every integration method shares the same primitives. Once you understand these, the surface API of any specific method is small.
Publisher ID
Every account gets a publisher ID like pub_xxx. Use it on every request — it's how Boost Boss attributes impressions and revenue. Sandbox publisher IDs (prefix pub_test_) work the same way but never accrue real revenue, never deliver real ads.
Context signal
You pass a context string with every ad request — the user's current intent, the tool name being called, the page topic, whatever signal best describes "what would be relevant right now." Boost Boss's matching engine uses this for contextual targeting. There is no cross-site tracking and no behavioral profile.
Disclosure
Every ad must be clearly labeled as sponsored. The integration libraries handle this automatically — the disclosure label is part of the rendered output, not something you add yourself. Hiding the disclosure is a policy violation.
Tracking pixels
Each ad response includes an impression_url and a click_url. Hit the impression URL after rendering; route user clicks through the click URL. The integration libraries do this for you on every method except raw REST.
Authentication
Most integration methods use a Bearer token from your dashboard. The JS snippet uses the public publisher ID instead — no secret needed because all the sensitive work happens server-side at Boost Boss.
| Method | Auth | Where the secret lives |
|---|---|---|
| MCP | Bearer token | Your server's environment |
| JS Snippet | Publisher ID (public) | HTML attribute |
| NPM SDK | Publisher ID (public) | Initialization options |
| REST API | Bearer token | Your server's environment |
Every page in these docs has a "Testing" section explaining how to use a sandbox publisher ID before you go live. Run sandbox until you've confirmed the integration end-to-end — there's no penalty for wasted sandbox calls.
Looking for the comprehensive API reference?
The single-page API reference covers fetch-ad endpoints, impression/click/conversion beacons, campaign management, the Benna ranking engine, ad formats, MCP integration internals, webhooks, rate limits, error codes, OpenRTB 2.6 (BBX adapter) bid request/response, and the changelog. Useful when you want to Ctrl-F something specific instead of browsing by integration method.
What's next
Pick the method that matches what you built and dive in. If you're not sure which applies to your stack, read the publisher overview first — it routes by what you built, then sends you to the right doc.