Boom Labs · Living Doc

SaaS API Access Hub

One place to track what every Boom SaaS app exposes as a consumable API, how to integrate it (into the BMBB dashboard or a client site), and the knowledge base for reselling API access to agencies & freelancers.

Last updated 2026-07-26 · Keep this current whenever an app's API changes.

READY keyed API a dashboard can consume today PARTIAL some endpoints, gaps remain NONE not built yet SPECIAL different integration shape

1Status matrix — every app at a glance 2The standard pattern (build once, copy per app) 3Per-app API reference 4Roadmap — what's left to build 5Reseller knowledge base (agencies & freelancers)

1. Status matrix

The BMBB dashboard is becoming a hub that embeds these apps as native API cards. Each app it shows data from needs a keyed read API. This is the source of truth for who's ready.

App	Status	Key auth	Key prefix	Endpoints	Notes
Replyee	READY	✅ `apiV1Auth`	`rpl_live_`	`/api/v1/me`, `/api/v1/chat`, `/api/keys`	+ leads webhook & spam blocklist. Keys stored plaintext (hash later); no keys UI page yet.
Rankee	READY	✅ `authenticateApiKey` (hashed)	`rk_live_`	`/api/v1/summary`, `/api/v1/optimize/:auditId`, `/account/api-keys`	Best key model of the suite (SHA-256 hashed). Summary card added 2026-07-26.
Bloggy	READY	✅ hashed `bloggy_api_keys`	`blg_live_`	`/api/v1/me`, `/api/v1/summary`, `/api/keys`	Built 2026-07-26. ⚠️ Run `schema-api-keys.sql`, then mint a key.
Localey	READY	✅ existing `lc_api_keys` (hashed, X-API-Key)	n/a	`/api/v1/me`, `/api/v1/summary`	Built 2026-07-26. No migration — reuses the BOO/Dashee key auth.
Posttee	READY	✅ hashed `pt_api_keys`	`pt_live_`	`/api/v1/me`, `/api/v1/summary`, `/api/keys`	Built 2026-07-26. ⚠️ Run `schema-api-keys.sql`, then mint a key.
Assistee	READY	✅ hashed `assistee_api_keys` (org-scoped)	`ast_live_`	`/api/v1/devices`, `/api/keys`	Built 2026-07-26 — device engine is still MeshCentral, but the hub card reads counts via this v1 endpoint. ⚠️ Run `schema-api-keys.sql`, then mint a key.

2. The standard pattern

Replyee's apiV1Auth was written to be reused. Every app that isn't ready gets the same four pieces (≈4 files). Do it once, copy-and-swap the app-specific summary.

Piece	File	What it does
Key auth	`lib/apiV1Auth.ts`	Reads `Authorization: Bearer <key>` or `X-API-Key`; looks up `{app}_api_keys`; returns the owner's `userId`. Hash the key (Rankee already does — copy that, not Replyee's plaintext).
Key mgmt	`api/keys/route.ts`	Signed-in owner lists / creates / revokes keys.
Identity	`api/v1/me/route.ts`	Validates the key + returns the account's resources (bots, sites, etc.).
Card data	`api/v1/summary/route.ts`	The app-specific dashboard payload. Each field in its own try/catch so the card never fails whole.

Plus a migration for the {app}_api_keys table. Auth is a Bearer key (not a cookie) because programmatic callers — the dashboard, n8n, Make, a reseller — can't present a cookie session.

Consumer side (the BMBB dashboard). Each card is a server-side fetch with the app's key stored as an env var, never in the browser:

const r = await fetch('https://rankee.online/api/v1/summary?domain=bigmikesbailbonds.com', {
  headers: { Authorization: `Bearer ${process.env.RANKEE_API_KEY}` },
  next: { revalidate: 300 },   // cache 5 min
})
const { avg_rank, keywords_tracked, latest_audit } = await r.json()

3. Per-app API reference

Replyee READY replyee.online

Method	Endpoint	Returns
GET	`/api/v1/me`	Validate key → list bots `{id,name,is_active}`
POST	`/api/v1/chat`	RAG answer. Body `{message,bot_id?,session_id?}`
GET/POST	`/api/keys`	Owner lists / mints keys (`rpl_live_…`)

curl -H "Authorization: Bearer rpl_live_xxx" https://replyee.online/api/v1/me

Also: per-bot lead webhook pushes captured leads to a client portal; spam blocklist at /api/leads/blocklist.

Rankee READY rankee.online

Method	Endpoint	Returns
GET	`/api/v1/summary?domain=`	`{websites, keywords_tracked, avg_rank, latest_audit}`
GET	`/api/v1/optimize/:auditId`	Fix-pack (json / markdown / issue / prompt)
—	`/account/api-keys`	Owner manages keys (`rk_live_…`, hashed)

curl -H "Authorization: Bearer rk_live_xxx" \
  "https://rankee.online/api/v1/summary?domain=example.com"

Bloggy / Localey / Posttee NONE

No public API yet — build the standard pattern (§2). Target summary payloads:

Bloggy /api/v1/summary → {published, drafts, scheduled, latest_posts[]}
Localey /api/v1/summary → {avg_rating, review_count, new_reviews, citations_ok}
Posttee /api/v1/summary → {scheduled, published_this_month, connected_accounts[]}

Assistee SPECIAL assistee.online

Backed by self-hosted MeshCentral (control.ashx WebSocket), not the v1 key pattern. For a hub card, add a thin /api/v1/devices returning {online, offline, total} from the devices table. Full device management (rename, client folders) lives in Assistee's own dashboard.

4. Roadmap

Bloggy — ✅ built (blg_live_, v1/me+v1/summary). Run schema-api-keys.sql.
Localey — ✅ built on existing lc_api_keys. No migration.
Posttee — ✅ built (pt_live_). Run schema-api-keys.sql.
Assistee — optional thin v1/devices count endpoint for the hub.
Harden Replyee — hash keys, add a keys settings UI page.
Verify summary columns on first deploy — Bloggy post status values, Posttee pt_posts.user_id, Localey lc_reviews.rating/lc_citations.status. Each field is guarded (degrades to 0/null), so adjust only if a card shows blanks.
Later: shared @boom/api-auth package so all apps import one key-auth implementation instead of copies.

5. Reseller knowledge base

For when you sell API access to agencies & freelancers. This is the model to standardize on across the suite before opening it up externally.

How access works

Every reseller gets an account in the app, then mints one or more API keys from their settings. A key is scoped to their account's data only — never cross-tenant.
Auth header: Authorization: Bearer <key> (or X-API-Key). Keys are prefixed per app (rpl_/rk_/blg_/lcl_/pt_) so they're identifiable in logs.
Keys are secrets — server-side only. Show the full key once at creation; store hashed (Rankee's model) so a DB leak can't reveal live keys.

What to add before selling externally

Area	Requirement
Hashing	All apps store SHA-256 hashes, not plaintext keys (Replyee still plaintext — fix first).
Rate limiting	Per-key limits (e.g. 60 req/min free, higher by tier). Return `429` + `Retry-After`.
Usage metering	`last_used_at` exists; add per-key request counts for billing & quotas.
Scopes	Read-only vs read-write keys; per-endpoint scopes for least privilege.
Revocation	One-click revoke in the keys UI (invalidate immediately).
Docs	Public reference per app (this hub is the internal version; a cleaned public copy for resellers).
Versioning	Everything under `/api/v1/` so a `/v2` never breaks existing resellers.

Suggested access tiers (draft — align with app pricing)

Tier	Rate	Use case
Free / trial	60 req/min, 10k/mo	Evaluation, a single embedded card
Agency	300 req/min, 500k/mo	White-label dashboards across many clients
Scale	Custom	High-volume / resale-to-resellers

Before any external sale: keys hashed everywhere, rate limiting live, revocation working, and a public docs copy. Internal hub use (BMBB dashboard) has none of these as blockers — start there, harden as you approach reselling.

Five apps are ready to consume (2026-07-26). Replyee, Rankee, Bloggy, Localey and Posttee all expose v1 read APIs. Bloggy & Posttee need their schema-api-keys.sql run + a key minted; Rankee/Localey/Replyee are live now. Assistee is the only remaining app (MeshCentral — optional device-count endpoint).

Boom Labs · SaaS API Access Hub · Update the status matrix (§1) whenever an app's API changes.
Related: Infrastructure & Cost · Replyee leads runbook in builds/replyee-leads-to-portal.html