Feature / API
Build on Brandloop without bypassing the brand engine.
Brandloop's developer platform gives teams API-key protected routes for brand source intake, asset upload and lookup, generation jobs, subject inspection, and an implemented OpenAPI contract. SDK and stdio MCP packages remain internal previews.
What developers can build around
Submit brand sources
Use the brand-intelligence source endpoint to queue a website or public profile for workspace-scoped brand intake.
Manage assets
Create asset upload records and retrieve asset metadata for brand references, generation inputs, outputs, or knowledge attachments.
Create generation jobs
Request generation jobs with workflow kind, inputs, output count, template key, assets, and idempotency behavior.
Developer-platform safeguards
- API-key subject endpoint
- `/api/v1/me` returns the key subject, scopes, mode, workspace, account, and rate-limit state.
- Shared OpenAPI document
- `/openapi.json` is built from shared API contracts instead of hand-maintained docs.
- SDK internal preview
- The private TypeScript package consumes the current generated OpenAPI artifact, but it has no public installation path, release ownership, or external smoke test.
- MCP with limits
- The remote endpoint uses the same API-key boundary for curated tools but has no OAuth flow. The local stdio package remains an internal preview.
API vs direct provider integration
| Alternative | Where it breaks | Brandloop approach |
|---|---|---|
| Calling providers directly | Provider keys leak into customer or agent workflows and bypass Brandloop review context. | Brandloop keeps providers behind scoped product APIs and workspace rules. |
| Internal scripts | Often lack OpenAPI contracts, idempotency, and shared SDK types. | Brandloop documents the public contract through generated OpenAPI; teams can generate their own external clients from it. |
| Browser-only automation | Harder to audit and brittle against UI changes. | Brandloop offers API and MCP paths for stable product-level operations. |
Current claim boundary
- The public API should not expose Supabase service-role keys, provider credentials, billing mutation internals, or destructive actions.
- The TypeScript SDK and stdio MCP server are private internal previews, not published packages with a supported install path.
- API access does not remove the need for brand review, workspace scoping, or approval gates.
Common questions
- Which public API routes exist?
- The current app includes `/api/v1/me`, `/api/v1/brand-intelligence/sources`, `/api/v1/assets`, `/api/v1/generations`, and generated OpenAPI at `/openapi.json`.
- Is there an SDK?
- There is an internal TypeScript SDK preview in the private monorepo. It is not published or supported for external installation; use the public OpenAPI contract for client generation.
- Can the API mutate billing or provider settings?
- No. Those are not public developer-platform promises. API and MCP surfaces should stay scoped to product operations.