REST API

Everything the dashboard and the portal can do goes through one internal API. A public REST layer exposes the parts of that API meant for other systems to call: reading a portal’s questions, asking a question on someone’s behalf, managing categories and tags, managing your team, and more. What’s off-limits is a short list: billing, creating or revoking API keys themselves, forum creation and sign-in, and a handful of session-only flows the portal’s own pages use internally. Everything else a dashboard role can do, an API key with that same role can do too.

Base path

The REST API lives at /api/v1 on the same host as your dashboard and portal. It’s a second way of talking to the same underlying procedures the dashboard’s own UI uses, not a separate product with its own rules.

Spec and reference

• The machine-readable spec is served at /api/v1/openapi.json, generated directly from the API’s own route definitions. It’s always current: a new capability can’t ship without also updating this spec.
• An interactive reference for browsing and trying endpoints lives at /api/v1/docs.
• A full written endpoint reference, generated from that same spec, is coming to this docs site. Until then, /api/v1/docs is the place to look.

What’s public today

Reading a portal is unauthenticated: fetching a portal’s public questions, a single question, a public user profile, or a portal’s top tags all work without any credentials, addressed by the portal’s subdomain. This is the same content anyone can already see by visiting the portal in a browser; the API just returns it as data instead of a page.

Authentication

Everything beyond public reads, asking a question, answering, voting, moderating, managing categories and tags, requires an API key sent as a Bearer token:

Authorization: Bearer <your-api-key>

Keys are created and revoked from the dashboard by a forum owner or admin, see API keys for how. A request with no key, an unrecognized key, or a malformed header gets 401 Unauthorized, there’s no partial or anonymous access to anything beyond the public reads above.

Every key carries a role, admin or agent, matched to the same roles your team already uses, plus an independent read-only modifier:

• Admin: matches an owner or admin’s reach in the dashboard, minus billing and key management, which stay dashboard-only for every key.
• Agent: day-to-day content work, answering and moderating, but not categories, tags, team, or settings.
• Read-only: layered on top of either role. Only the API’s GET endpoints, anything else is rejected, regardless of what the role would otherwise allow.

A key’s power is capped by its creator’s current role, so removing or demoting a creator narrows or disables the keys they made on the next request. See API keys for the full picture, including how to create one and what each role and modifier allows in more detail.

Next steps

• API keys
• Plans & limits
• Invite team members & roles