Workspace Whitepapers

/whitepapers manages gated whitepaper downloads: upload the asset, publish the landing content, review captured leads, and export them for sales follow-up. Delivery fans out to AWS SES (email), Slack (notifications), and Google Sheets.

Routes and guards#

Route	Purpose	Guard
`/whitepapers`	Admin list + stats (`WhitepapersAdminPage`)	`org:content:view` (`page.tsx` + `layout.tsx`)

Entry point: page.tsx and layout.tsx both enforce requirePermission("org:content:view"). Client state lives in hooks/useWhitepapers.ts with shared types.ts / constants.ts.

Backing API routes#

Unlike the /api/workspace/* modules, this area uses the legacy admin tree:

Route	Purpose	Clearance
`/api/whitepapers/admin`	List / create whitepapers	`org:content:view` / `org:content:create`
`/api/whitepapers/admin/[id]`	Update / delete one	`org:content:edit` / `org:content:delete`
`/api/whitepapers/admin/leads`	Captured-lead inbox	`org:leads:view`
`/api/whitepapers/admin/leads/export`	CSV lead export	`org:leads:export` (10/hour/user + audit log)
`/api/whitepapers/admin/stats`	Download / conversion stats	`org:analytics:view`
`/api/whitepapers/admin/upload/wordpress`	WordPress media attach for cover assets	`org:content:create`
`/api/whitepapers/admin/health`, `/test/*`	Integration health + MongoDB/Sheets/Slack self-tests	`org:dev:tools_access`

Backed by MongoDB whitepapers and whitepaper_leads.

Notable behaviour#

Lead export is the sensitive path: gated on org:leads:export, rate-limited to 10/hour/user, and every export writes an audit log entry.
The /test/* self-test routes verify MongoDB, Google Sheets, and Slack wiring without touching production lead data — use them when onboarding a new whitepaper.

Related: Audience · Sales · Datasheets

Loading…