API overview¶
Autopoetic exposes three programmatic surfaces. They share one authentication scheme — project API keys — but serve different jobs:
| Surface | Use it to | Shape |
|---|---|---|
| Responses API | Talk to an agent. Generate responses with streaming, perspectives, and steering metadata. | OpenAI Responses-compatible, SSE |
| Platform API | Manage your workspace. Read and write conversations, messages, knowledge, projects, members, and workflows. | REST, project-scoped |
| MCP server | Do the same management from LLM clients, IDEs, and agents. | Model Context Protocol |
Which one do I need?¶
- If your code wants an answer from the agent — use the Responses API.
- If your code wants to organize, search, or export what's already there — use the platform API (or the MCP server from an LLM client).
The two HTTP APIs differ in one load-bearing way: agent generation happens only on the Responses API. Appending a user message through the platform API stores it (encrypted, metered) without generating anything — a follow-up Responses call can then pick the conversation up and produce the agent's turn. The platform API never runs inference; the Responses API never manages members, forks, exports, or knowledge structure.
Authentication¶
All three surfaces authenticate with the same Bearer credentials — project API keys created on the API Keys page (admin role). See projects and teams.
The endpoint reference¶
Every REST endpoint — the platform API and the workflows surface — is documented in the live OpenAPI schema page:
- https://app.autopoetic.ai/schema — the rendered reference (Redoc)
- https://app.autopoetic.ai/schema/openapi.json — the raw spec, for code generation and tooling
- https://app.autopoetic.ai/schema/swagger — Swagger UI
The schema is generated from the deployed server, so it always matches what your code is talking to. The platform API page explains the surface's conventions; the schema is the authoritative endpoint table.