API reference

Everything InfoEmu does is a plain HTTP API. Four surfaces, four token types — each scoped to exactly what it needs to do.

Authentication at a glance

Deploy tokens (dpl_…, header Authorization: Bearer) — scoped to one site; mint and revoke them from your dashboard. Made for CI and agents.
Account session — your dashboard login manages sites, billing, and instance settings.
Forum tokens (header Authentication-Token) — per-user tokens on your forum instance; with public read enabled, read endpoints work anonymously.
Content API keys (blu_sk_…) — per-user keys for the headless CMS. API access is included on Pro plans and above; deploy tokens come with every static or docs site.

Deploy API

Base: your portal origin (portal.infoemu.com), auth: deploy token.

Call	What it does
POST /api/deploy/{id}	Upload a built site (multipart field "archive", tar.gz) — becomes an immutable release
POST /api/deploy/{id}/source	Upload raw Markdown content — we build it in a sandbox; failures return logs, never a broken site
GET /api/deploy/{id}/builds	Build jobs with state and logs (also /builds/{build_id})
GET /api/deploy/{id}/releases	Releases plus aliases: what's live, what's staged, per-release preview hostnames
POST /api/deploy/{id}/promote	{"release": "<id>"} — make a release live (atomic)
PUT/DELETE /api/deploy/{id}/stage	Point or clear the stage-- alias at a release
POST /api/deploy/{id}/rollback	Revert production to the previous release
PUT /api/deploy/{id}/github	Connect a GitHub repo + branch; pushes build automatically, other branches build preview-only

A complete deploy loop in four calls:

tar -czf site.tar.gz -C dist .
curl -X POST "$PORTAL/api/deploy/$ID" -H "Authorization: Bearer $TOKEN" -F "archive=@site.tar.gz"
curl "$PORTAL/api/deploy/$ID/releases" -H "Authorization: Bearer $TOKEN"   # → preview URL
curl -X POST "$PORTAL/api/deploy/$ID/promote" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" -d '{"release": "<release-id>"}'

Instance settings API

Call	What it does
GET/PUT /api/instances/{id}/env	Allowlisted per-site settings (e.g. FORUM_API_PUBLIC_READ, API_CORS_ORIGINS) — PUT replaces the map
POST /api/instances/{id}/restart	Apply setting changes (converges the stack to its configured state)

Forum API

Base: https://your-forum/api/forum/v1. Wire format is snake_case JSON; lists paginate with page/page_size and an X-Pagination header.

Call	What it does
GET /forums · GET /forums/{id}	List forums / one forum (id or slug)
GET /topics?forum_id= · GET /topics/{id}	Topics in a forum / one topic
GET /topics/{id}/posts?view=threaded	Posts, threaded or classic
POST /topics · POST /topics/{id}/posts	Create a topic / reply (optionally to a parent post)

Reads can be public: enable FORUM_API_PUBLIC_READ and set API_CORS_ORIGINS via the instance settings API, and anonymous visitors get the same guest-visibility rules as your forum's web UI. Our @infoemu/react components render live threads on any page this way.

Content (headless CMS) API

Call	What it does
GET/POST /api/cms/v1/entries/{type}	List / create content entries for a content type (API-key auth)
GET/PUT /api/cms/v1/entries/{type}/{id}	Read / update an entry
GET /api/cms/v1/content-types	Your content model
POST /api/cms/v1/ai-content/generate	AI content drafting — enabled per site with your own Anthropic API key (off by default)

Help desk API

Call	What it does
GET/POST /api/helpdesk/v1/tickets	List / create support tickets
GET/POST /api/helpdesk/v1/tickets/{id} …	Ticket thread, replies, triage (agent permissions apply)
POST /api/helpdesk/v1/inbound-email	Inbound-email webhook (Mailgun/Postmark) — mail to your support address becomes a ticket, threaded both ways

For AI agents

The APIs above are designed to be agent-drivable: see the agent tutorial for the paste-ready brief and safety model, and llms.txt for the machine-readable version of this page.